* [RESEND PATCH] fast-import: Cleanup mode setting.
From: Felipe Contreras @ 2009-01-14 1:37 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Johannes Schindelin, Miklos Vajna,
Felipe Contreras
"S_IFREG | mode" probably is only required for 0644 and 0755.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
fast-import.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index a6bce66..f0e08ac 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1872,12 +1872,13 @@ static void file_change_m(struct branch *b)
if (!p)
die("Corrupt mode: %s", command_buf.buf);
switch (mode) {
+ case 0644:
+ case 0755:
+ mode |= S_IFREG;
case S_IFREG | 0644:
case S_IFREG | 0755:
case S_IFLNK:
case S_IFGITLINK:
- case 0644:
- case 0755:
/* ok */
break;
default:
@@ -1944,7 +1945,7 @@ static void file_change_m(struct branch *b)
typename(type), command_buf.buf);
}
- tree_content_set(&b->branch_tree, p, sha1, S_IFREG | mode, NULL);
+ tree_content_set(&b->branch_tree, p, sha1, mode, NULL);
}
static void file_change_d(struct branch *b)
--
1.6.0.6.5.ga66c
^ permalink raw reply related
* Re: [announce] gc
From: Jakub Narebski @ 2009-01-14 1:31 UTC (permalink / raw)
To: git
In-Reply-To: <20081222212407.47c9ab1e.stephen@exigencecorp.com>
Stephen Haberman wrote:
> This is just a small collections of hooks, scripts, and practices I
> developed while working on a not-distributed/corporate project.
>
> A quick list is: svn-like revision numbers (via tagging every commit)
> (don't flame me, please), combined diff-enabled commit emails*, Hudson
> hooks, trac hooks, branch locking, same-repo-separate-DAG git
> server-side config storage and export-on-push, and developer-side
> push/pull scripts that "just work".
>
> http://github.com/stephenh/gc
>
> Hopefully others find it as useful.
Added to http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Jay Soffian @ 2009-01-14 0:58 UTC (permalink / raw)
To: Vladimir Pouzanov; +Cc: git, Eric Wong
In-Reply-To: <loom.20090113T213400-985@post.gmane.org>
On Tue, Jan 13, 2009 at 4:34 PM, Vladimir Pouzanov <farcaller@gmail.com> wrote:
> Jay Soffian <jaysoffian <at> gmail.com> writes:
>> Perhaps this will help in tracking down the problem.
>
> $ git svn clone http://qsb-mac.googlecode.com/svn/trunk qsb-mac
> Initialized empty Git repository in /Users/farcaller/temp/qsb-mac/.git/
> r1 = 810fe584c48b884460b5403a28bc61d872452b93 (git-svn)
> Temp file with moniker 'svn_delta' already in use at /opt/local/lib/perl5/
> site_perl/5.8.8/Git.pm line 1011.
One more thing to try. Edit your Git.pm and make the top of
_temp_cache() look like the following:
sub _temp_cache {
my ($self, $name) = _maybe_self(@_);
use Carp qw(longmess);
warn longmess() if $name eq "svn_delta";
So you're adding the "use Carp..." and "warn..." lines.
Then try the import again. That should at least show why the svn_delta
temp file is being acquired twice.
(Yes, this is the printf school of debugging...)
j.
^ permalink raw reply
* [PATCH/RFC] git-svn: Add --convert-timezone option
From: Pete Harlan @ 2009-01-14 0:45 UTC (permalink / raw)
To: Eric Wong, Git mailing list
By default git svn stores timestamps of fetched commits in
Subversion's UTC format, to facilitate interoperating with a
Subversion repository.
If you're using git svn to convert a repository to Git and aren't
interested in pushing Git commits back to Subversion, you can use this
option to store timestamps of fetched commits as though they were made
in the local timezone of the host on which git svn is run. This makes
the times and timezones of a resulting "git log" agree with what "svn
log" shows for the same repository.
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
This is a patch I've had floating around for a while. I haven't
submitted it before because I find the solution ungainly. There has
to be a better way to convert from one timezone to the other, but I
didn't run across it and now that I've converted away from Subversion
I'm sort of done thinking about it. I'm submitting it now because
even in its current state it would have saved me some headache.
Also, I'm not sure I'm correct when asserting that converting
timezones like this will break Subversion interoperability. Eric, if
that isn't true then I can remove that claim and resubmit. If
converting timezones breaks nothing, then maybe it could even be the
default.
One improvement that I didn't bother to make would be to convert to
different local timezones based on author. This change uses the
timezone of the machine running git-svn, which in my case was fine.
Using per-author timezones would be nice, but since parse_svn_date()
doesn't already know which author the date is associated with it would
be a more intrusive change.
My primary motivation in this was to reduce transition shock among our
development team. The fewer ways "git log" looks unhelpfully
different than the old "svn log" the better; converting all commit
times into GMT wasn't going to look friendly.
Comments welcome.
--Pete
Documentation/git-svn.txt | 8 ++++
contrib/completion/git-completion.bash | 2 +-
git-svn.perl | 56 ++++++++++++++++++++++++++++++-
3 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 8d0c421..8811bf0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -92,6 +92,14 @@ COMMANDS
.git/config file may be specified as an optional command-line
argument.
+--convert-timezones;;
+ Store Git commit times in the local timezone instead of UTC. This
+ makes 'git-log' (even without --date=local) show the same times
+ that `svn log` would in the local timezone.
+
+This breaks interoperability with SVN, but may be cosmetically
+desirable when converting a repository from SVN to Git.
+
'clone'::
Runs 'init' and 'fetch'. It will automatically create a
directory based on the basename of the URL passed to it;
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8ec782d..597ef3d 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1560,7 +1560,7 @@ _git_svn ()
--follow-parent --authors-file= --repack=
--no-metadata --use-svm-props --use-svnsync-props
--log-window-size= --no-checkout --quiet
- --repack-flags --user-log-author $remote_opts
+ --repack-flags --user-log-author --convert-timezones $remote_opts
"
local init_opts="
--template= --shared= --trunk= --tags=
diff --git a/git-svn.perl b/git-svn.perl
index ad01e18..c2f600d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -66,7 +66,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url, $_tag);
+ $_git_format, $_commit_url, $_tag, $_convert_timezones);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -84,6 +84,7 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
\$Git::SVN::_repack_flags,
'use-log-author' => \$Git::SVN::_use_log_author,
'add-author-from' => \$Git::SVN::_add_author_from,
+ 'convert-timezones' => \$_convert_timezones,
%remote_opts );
my ($_trunk, $_tags, $_branches, $_stdlayout);
@@ -2526,12 +2527,63 @@ sub get_untracked {
\@out;
}
+# parse_svn_date(DATE)
+# --------------------
+# Given a date (in UTC) from Subversion, return a string in the format
+# "<TZ Offset> <local date/time>" that Git will use.
+#
+# By default the parsed date will be in UTC for interoperating with
+# Subversion, but if $_convert_timezones is true we'll convert it to
+# the local timezone instead.
sub parse_svn_date {
my $date = shift || return '+0000 1970-01-01 00:00:00';
my ($Y,$m,$d,$H,$M,$S) = ($date =~ /^(\d{4})\-(\d\d)\-(\d\d)T
(\d\d)\:(\d\d)\:(\d\d).\d+Z$/x) or
croak "Unable to parse date: $date\n";
- "+0000 $Y-$m-$d $H:$M:$S";
+ my $parsed_date; # Set next.
+
+ if ($_convert_timezones) {
+ # Translate the Subversion datetime to an epoch time.
+ # We need to switch ourselves to $date's timezone,
+ # UTC, for this.
+ my $oldEnvTZ = $ENV{TZ};
+ $ENV{TZ} = 'UTC';
+
+ my $epochUTC =
+ POSIX::strftime ('%s', $S, $M, $H, $d, $m - 1, $Y - 1900);
+
+ # Determine our local timezone (including DST) at the
+ # time of $epochUTC. $Git::SVN::Log::TZ stored the
+ # value of TZ, if any, at the time we were run.
+ if (defined $Git::SVN::Log::TZ) {
+ $ENV{TZ} = $Git::SVN::Log::TZ;
+ } else {
+ delete $ENV{TZ};
+ }
+
+ my $ourTZ =
+ POSIX::strftime ('%Z', $S, $M, $H, $d, $m - 1, $Y - 1900);
+
+ # This converts $epochUTC into our local timezone.
+ my ($sec, $min, $hour, $mday, $mon, $year,
+ $wday, $yday, $isdst) = localtime ($epochUTC);
+
+ $parsed_date = sprintf ('%s %04d-%02d-%02d %02d:%02d:%02d',
+ $ourTZ, $year + 1900, $mon + 1,
+ $mday, $hour, $min, $sec);
+
+ # Reset us to the timezone in effect when we entered
+ # this routine.
+ if (defined $oldEnvTZ) {
+ $ENV{TZ} = $oldEnvTZ;
+ } else {
+ delete $ENV{TZ};
+ }
+ } else {
+ $parsed_date = "+0000 $Y-$m-$d $H:$M:$S";
+ }
+
+ return $parsed_date;
}
sub check_author {
--
1.6.1.77.g56257
^ permalink raw reply related
* Re: [PATCH] gitweb: recognize six digit abbreviated SHA1
From: Sam Vilain @ 2009-01-14 0:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anders Melchiorsen, git, jnareb
In-Reply-To: <7vd4erd32a.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> When people give an abbreviated object name, 99% of the time they mean
> commits (and "index deadbeef..acebead" in a patch is a good place to pick
> blob object names from, which would be what the 99% of the remaining 1%
> would name), so making sure it is a commit or a blob would be a very
> sensible thing to do.
>
> Unfortunately, you fundamentally cannot do this without taking a
> performance hit of actually opening the object.
>
Yeah. I envisioned this just for those cases where the tool would
otherwise return 'ambiguous argument'; if there was a hint as to the
object type, open *all* the matching objects and return the one that
matched the type only.
Sam.
^ permalink raw reply
* Re: How can I restrict git-diff to a specific set of directories?
From: Alan @ 2009-01-14 0:33 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20090114000220.GB12624@atjola.homenet>
On Wed, 2009-01-14 at 01:02 +0100, Björn Steinbrink wrote:
> On 2009.01.13 15:49:03 -0800, Alan wrote:
> > I have a repository that I need to build a set of patches for a single
> > directory path. (I just want the diffs on the one driver.)
> >
> > Is there a clean non-hacky way to do this?
> >
> > It is not cross repository or anything. I just need to generate a diff
> > between one commit and another, but only for the contents of a specific
> > directory.
> >
> > I am not finding a real straightforward way to do that. (Unless I am
> > missing something, which is quite possible.)
>
> git diff commitA commitB -- some/paths/here some/more/here and/then/some
>
> That limits the diff to the paths after the dashes.
Thanks! That is EXACTLY what I need.
^ permalink raw reply
* [RFC/PATCH] gitweb: Fix nested links problem with ref markers
From: Jakub Narebski @ 2009-01-14 0:17 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0901121659h7277c074ia73786b15d66b804@mail.gmail.com>
On Tue, 13 Jan 2009, Giuseppe Bilotta wrote:
> On Mon, Jan 12, 2009 at 7:13 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Mon, 12 Jan 2009, Giuseppe Bilotta wrote:
>>> On Sun, Jan 11, 2009 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
[...]
> Notice that nested links are actually valid *XML*. Indeed, I asked on
> www-style and they suggested leaving the problem as-is, serving as
> html+xml which is what we do.
But nested links are neither valid HTML nor valid XHTML. This
restriction (no nested links) is IMVHO quite sensible, but IIRC
it simply cannot be expressed as pure XML restriction (DTD, XML Schema,
Relax-NG... perhaps Sablotron can express this restriction).
>>>> * Revert 4afbaef (we lose feature, but how often used is it?)
>>>> * Always use quirks mode, or check browser and use quirks mode if it
>>>> would break layout
>>>> * Use extra divs and links and CSS positioning to make layout which
>>>> looks like current one, and behaves as current one, but is more
>>>> complicated.
>>>
>>> I'm asking on #html, hopefully I'll get some interesting idea to try for this.
>>
>> I have found _a_ solution. Perhaps not the best one, but it works.
>> And IMHO gives / can give even better visual.
>>
>> Current version (line wrapped for better visibility):
[...]
>> Proposed code (line wrapped for better visibility, with CSS embedded,
>> which would change in final version of course). Only parts of style
>> related to positioning are shown.
>> <div class="header">
>> <a href="..." style="float: left; margin: 6px 1px 6px 8px;">GIT 1.6.1</a>
>> <div style="float: left; margin: 6px 1px;">
>> <span class="refs">
>> <span class="tag indirect" title="tags/v1.6.1">
>> <a href="...">v1.6.1</a>
>> </span>
>> </span>
>> </div>
>> <a href="..." style="display: block; padding: 6px 8px;"> </a>
>> </div>
[...]
>> What do you think?
>
> The float thing was the second suggestion I was given on www-style.
What was the first suggestion? And what is www-style?
> Can you provide a patch I can apply to my tree for testing to see how
> it comes up?
Here it is. Note that CSS could be I think reduced. The size of
gitweb.perl changes is affected by changing calling convention for
git_print_header_html subroutine.
There is also strange artifact at least in Mozilla 1.17.2: if I hover
over ref marker, the subject (title) gets darker background. Curious...
-- >8 --
From: Jakub Narebski <jnareb@gmail.com>
Date: Wed, 14 Jan 2009 01:07:30 +0100
Subject: [RFC/PATCH] gitweb: Fix nested links problem with ref markers
Now that ref markers are links, they create nested links which are not
allowed in HTML, and in strict mode in some browsers it causes layout
errors.
It fixes format_subject_html subroutine (used for example in
'shortlog' view) to put $extra (which currently is formatted ref
marker) outside "subject" link, as $extra can contain links and in
HTML links cannot be nested.
It changes calling convention of git_print_header_div (and accordingly
its calling sites) to provide $ref as separate argument, instead of
concatenating it and putting it in $title, and provides workaround so
links are not nested.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.css | 25 +++++++++++++++++++++-
gitweb/gitweb.perl | 56 ++++++++++++++++++++++++++++++++-------------------
2 files changed, 58 insertions(+), 23 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index a01eac8..244eea2 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -76,23 +76,44 @@ div.page_body {
font-family: monospace;
}
-div.title, a.title {
+div.title, a.block {
display: block;
padding: 6px 8px;
+ text-decoration: none;
+ background-color: #edece6;
+}
+
+div.title, a.title {
font-weight: bold;
background-color: #edece6;
text-decoration: none;
color: #000000;
}
+div.header div.extra,
+div.header a.float {
+ float: left;
+ margin: 6px 1px;
+}
+
+div.header a.float {
+ margin: 6px 1px 6px 8px;
+}
+
div.readme {
padding: 8px;
}
-a.title:hover {
+a.block:hover,
+div.header:hover a.title {
background-color: #d9d8d1;
}
+div.header a.title:hover {
+ background-color: #edece6; /* ??? */
+ text-decoration: underline;
+}
+
div.title_text {
padding: 6px 0px;
border: solid #d9d8d1;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0ac84d1..9c192ba 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1408,6 +1408,7 @@ sub format_ref_marker {
}
# format, perhaps shortened and with markers, title line
+# $extra can contain links, and nested links are illegal in HTML
sub format_subject_html {
my ($long, $short, $href, $extra) = @_;
$extra = '' unless defined($extra);
@@ -1415,10 +1416,10 @@ sub format_subject_html {
if (length($short) < length($long)) {
return $cgi->a({-href => $href, -class => "list subject",
-title => to_utf8($long)},
- esc_html($short) . $extra);
+ esc_html($short)) . $extra;
} else {
return $cgi->a({-href => $href, -class => "list subject"},
- esc_html($long) . $extra);
+ esc_html($long)) . $extra;
}
}
@@ -3146,17 +3147,30 @@ sub format_paging_nav {
## functions printing or outputting HTML: div
sub git_print_header_div {
- my ($action, $title, $hash, $hash_base) = @_;
+ my ($action, $title, $ref, $hash, $hash_base) = @_;
my %args = ();
$args{'action'} = $action;
$args{'hash'} = $hash if $hash;
$args{'hash_base'} = $hash_base if $hash_base;
- print "<div class=\"header\">\n" .
- $cgi->a({-href => href(%args), -class => "title"},
- $title ? $title : $action) .
- "\n</div>\n";
+ my $href = href(%args);
+ if ($ref) {
+ # $ref can contain links, and nested links are illegal in HTML
+ # that is why we do this trick (see also gitweb.css for style)
+ # of title text, ref markers and 'background' link
+ print "<div class=\"header\">\n" .
+ $cgi->a({-href => $href, -class => "title float"},
+ $title ? $title : $action) . "\n" .
+ "<div class=\"extra\">\n$ref\n</div>\n" .
+ $cgi->a({-href => $href, -class => "block"}, ' ') .
+ "\n</div>\n"; # class="header"
+ } else {
+ print "<div class=\"header\">\n" .
+ $cgi->a({-href => $href, -class => "title block"},
+ $title ? $title : $action) .
+ "\n</div>\n"; # class="header"
+ }
}
#sub git_print_authorship (\%) {
@@ -3781,7 +3795,7 @@ sub git_patchset_body {
while ($patch_line) {
# parse "git diff" header line
- if ($patch_line =~ m/^diff --git (\"(?:[^\\\"]*(?:\\.[^\\\"]*)*)\"|[^ "]*) (.*)$/) {
+ if ($patch_line =~ m/^diff --git (\"(?:[^\\\"]*(?:\\.[^\\\"]*)*)\"|[^ \"]*) (.*)$/) {
# $1 is from_name, which we do not use
$to_name = unquote($2);
$to_name =~ s!^b/!!;
@@ -4523,7 +4537,7 @@ sub git_tag {
die_error(404, "Unknown tag object");
}
- git_print_header_div('commit', esc_html($tag{'name'}), $hash);
+ git_print_header_div('commit', esc_html($tag{'name'}), undef, $hash);
print "<div class=\"title_text\">\n" .
"<table class=\"object_header\">\n" .
"<tr>\n" .
@@ -4591,7 +4605,7 @@ sub git_blame {
$cgi->a({-href => href(action=>"blame", file_name=>$file_name)},
"HEAD");
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash_base);
git_print_page_path($file_name, $ftype, $hash_base);
# page body
@@ -4797,7 +4811,7 @@ sub git_blob {
"raw");
}
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash_base);
} else {
print "<div class=\"page_nav\">\n" .
"<br/><br/></div>\n" .
@@ -4870,7 +4884,7 @@ sub git_tree {
push @views_nav, $snapshot_links;
}
git_print_page_nav('tree','', $hash_base, undef, undef, join(' | ', @views_nav));
- git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash_base);
+ git_print_header_div('commit', esc_html($co{'title'}), $ref, $hash_base);
} else {
undef $hash_base;
print "<div class=\"page_nav\">\n";
@@ -5009,7 +5023,7 @@ sub git_log {
my %ad = parse_date($co{'author_epoch'});
git_print_header_div('commit',
"<span class=\"age\">$co{'age_string'}</span>" .
- esc_html($co{'title'}) . $ref,
+ esc_html($co{'title'}), $ref,
$commit);
print "<div class=\"title_text\">\n" .
"<div class=\"log_link\">\n" .
@@ -5097,9 +5111,9 @@ sub git_commit {
$formats_nav);
if (defined $co{'parent'}) {
- git_print_header_div('commitdiff', esc_html($co{'title'}) . $ref, $hash);
+ git_print_header_div('commitdiff', esc_html($co{'title'}), $ref, $hash);
} else {
- git_print_header_div('tree', esc_html($co{'title'}) . $ref, $co{'tree'}, $hash);
+ git_print_header_div('tree', esc_html($co{'title'}), $ref, $co{'tree'}, $hash);
}
print "<div class=\"title_text\">\n" .
"<table class=\"object_header\">\n";
@@ -5292,7 +5306,7 @@ sub git_blobdiff {
git_header_html(undef, $expires);
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash_base);
} else {
print "<div class=\"page_nav\"><br/>$formats_nav<br/></div>\n";
print "<div class=\"title\">$hash vs $hash_parent</div>\n";
@@ -5462,7 +5476,7 @@ sub git_commitdiff {
git_header_html(undef, $expires);
git_print_page_nav('commitdiff','', $hash,$co{'tree'},$hash, $formats_nav);
- git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash);
+ git_print_header_div('commit', esc_html($co{'title'}), $ref, $hash);
git_print_authorship(\%co);
print "<div class=\"page_body\">\n";
if (@{$co{'comment'}} > 1) {
@@ -5579,7 +5593,7 @@ sub git_history {
git_header_html();
git_print_page_nav('history','', $hash_base,$co{'tree'},$hash_base, $paging_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash_base);
git_print_page_path($file_name, $ftype, $hash_base);
git_history_body(\@commitlist, 0, 99,
@@ -5660,13 +5674,13 @@ sub git_search {
}
git_print_page_nav('','', $hash,$co{'tree'},$hash, $paging_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash);
git_search_grep_body(\@commitlist, 0, 99, $next_link);
}
if ($searchtype eq 'pickaxe') {
git_print_page_nav('','', $hash,$co{'tree'},$hash);
- git_print_header_div('commit', esc_html($co{'title'}), $hash);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash);
print "<table class=\"pickaxe search\">\n";
my $alternate = 1;
@@ -5735,7 +5749,7 @@ sub git_search {
if ($searchtype eq 'grep') {
git_print_page_nav('','', $hash,$co{'tree'},$hash);
- git_print_header_div('commit', esc_html($co{'title'}), $hash);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash);
print "<table class=\"grep_search\">\n";
my $alternate = 1;
--
1.6.0.4
^ permalink raw reply related
* Re: How can I restrict git-diff to a specific set of directories?
From: Björn Steinbrink @ 2009-01-14 0:02 UTC (permalink / raw)
To: Alan; +Cc: git
In-Reply-To: <1231890543.31432.5.camel@rotwang.fnordora.org>
On 2009.01.13 15:49:03 -0800, Alan wrote:
> I have a repository that I need to build a set of patches for a single
> directory path. (I just want the diffs on the one driver.)
>
> Is there a clean non-hacky way to do this?
>
> It is not cross repository or anything. I just need to generate a diff
> between one commit and another, but only for the contents of a specific
> directory.
>
> I am not finding a real straightforward way to do that. (Unless I am
> missing something, which is quite possible.)
git diff commitA commitB -- some/paths/here some/more/here and/then/some
That limits the diff to the paths after the dashes.
Björn
^ permalink raw reply
* Re: How can I restrict git-diff to a specific set of directories?
From: Boyd Stephen Smith Jr. @ 2009-01-14 0:02 UTC (permalink / raw)
To: Alan; +Cc: git
In-Reply-To: <1231890543.31432.5.camel@rotwang.fnordora.org>
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
On Tuesday 2009 January 13 17:49:03 Alan wrote:
>I need to generate a diff
>between one commit and another, but only for the contents of a specific
>directory.
>
>I am not finding a real straightforward way to do that.
I think:
git diff one_commit another -- specific/directory
is supposed to do what you want. However, I've never used it myself.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Getting new branches from SVN?
From: Björn Steinbrink @ 2009-01-13 23:55 UTC (permalink / raw)
To: Andrew Selder; +Cc: git
In-Reply-To: <loom.20090113T234017-639@post.gmane.org>
On 2009.01.13 23:44:13 +0000, Andrew Selder wrote:
> Hi.
>
> We started using git-svn at my company and it's going pretty well so far.
>
> The only problem I have is that when new branches and tags are created in SVN,
> how do I get those branches to show up in git as remote branches.
>
> I did the normal git svn clone -s -prefix svn/ .... and it found all the
> branches and tags up to that point.
>
> But since then, a couple new SVN branches and tags have been created, and I need
> them to appear in my git repo.
>
> I'm sure I just missed something simple, but I couldn't find this.
"git svn fetch" should get them.
Björn
^ permalink raw reply
* How can I restrict git-diff to a specific set of directories?
From: Alan @ 2009-01-13 23:49 UTC (permalink / raw)
To: git
I have a repository that I need to build a set of patches for a single
directory path. (I just want the diffs on the one driver.)
Is there a clean non-hacky way to do this?
It is not cross repository or anything. I just need to generate a diff
between one commit and another, but only for the contents of a specific
directory.
I am not finding a real straightforward way to do that. (Unless I am
missing something, which is quite possible.)
Thanks!
^ permalink raw reply
* Getting new branches from SVN?
From: Andrew Selder @ 2009-01-13 23:44 UTC (permalink / raw)
To: git
Hi.
We started using git-svn at my company and it's going pretty well so far.
The only problem I have is that when new branches and tags are created in SVN,
how do I get those branches to show up in git as remote branches.
I did the normal git svn clone -s -prefix svn/ .... and it found all the
branches and tags up to that point.
But since then, a couple new SVN branches and tags have been created, and I need
them to appear in my git repo.
I'm sure I just missed something simple, but I couldn't find this.
Thanks,
Andrew
^ permalink raw reply
* [ANNOUNCE] tig-0.13
From: Jonas Fonseca @ 2009-01-13 23:36 UTC (permalink / raw)
To: git
Hello,
This release contains a major rewrite of the IO layer of tig to use
fork+exec instead of popen() and remove use of stdio's fopen() and
friends. The new IO API removes the need for shell quoting and improves
the overall speed of loading view data. On the downside, it brings a few
incompatibilities wrt. commands given via the environment. While the
patch series began by being based on git's run-command.c module, the
final version contains no code from git.
The release also brings a few new features, such as new identifiers for
use in external commands as well as a handful of bug fixes.
What is tig?
------------
Tig is an ncurses-based text-mode interface for git. It functions mainly
as a git repository browser, but can also assist in staging changes for
commit at chunk level and act as a pager for output from various git
commands.
- Homepage: http://jonas.nitro.dk/tig/
- Manual: http://jonas.nitro.dk/tig/manual.html
- Tarballs: http://jonas.nitro.dk/tig/releases/
- Git URL: git://repo.or.cz/tig.git
- Gitweb: http://repo.or.cz/w/tig.git
Release notes
-------------
Incompatibilities:
- Commands from the environment (e.g. TIG_MAIN_CMD) will no longer have
access to shell features, such as subshells and variable expansion.
The easiest way to upgrade your configuration is to put such commands
in a script file.
Improvements:
- Display repository references in the sorted order: tags, heads,
tracked remotes, remotes.
- Add bash completion for blame.
- Tree view: edit files of the current branch.
- Run requests: new identifiers %(directory), %(file), and %(ref)
- Improve responsiveness and view loading speed by using select(2).
Bug fixes:
- Separate blame revision and file argument by "--" to avoid problems.
- Main view: fix redrawing of the last commit wrt. the revision graph.
- Fix waiting for input after executing a run request in pager mode.
- Status & stage view: refuse to open directories and deleted files.
- Tree view: show error when requesting blame for all non-file entries.
- Do not draw loading views, which are not displayed.
- Fix launching of mergetool from a subdirectory.
Change summary
--------------
The diffstat and log summary for changes made in this release.
NEWS | 29 +
VERSION | 2 +-
contrib/announcement.sh | 2 +-
contrib/tig-completion.bash | 25 +-
manual.txt | 281 ++++---
tig.1.txt | 6 +-
tig.c | 1774 +++++++++++++++++++++--------------
tigrc.5.txt | 23 +-
8 files changed, 1325 insertions(+), 817 deletions(-)
53 Jonas Fonseca
--
Jonas Fonseca
^ permalink raw reply
* Re: egit problem with sym linked eclipse project dirs
From: Stephen Bannasch @ 2009-01-13 23:27 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git, Scott Cytacki
In-Reply-To: <200901132237.11946.robin.rosenberg.lists@dewire.com>
At 10:37 PM +0100 1/13/09, Robin Rosenberg wrote:
> > To hack around Eclipse's problem with projects in nested directories
>> I clone a repo and then create a new top-level dir that just has
>> symbolic links to all the project directories.
>>
>> However when I Team/Share with git using egit the resources become
>> untracked when displayed in Eclipse -- they still are tracked however
>> when I check from the command line.
>
>I've seen this too, but so far not got myself to actually fix it. I
>think it has do with
>that we ask eclipse project for it's path end there we gets off track. Thanks
>for providing a good example that help "someone" to fix it.
>
>Could you add an issue at http://code.google.com/p/egit/issues/list and maybe
>include a tar ball with a simple project displaying this behaviour?
>(with a note
>that the symlinks makes this impossible to recreate on Windows).
Done: http://code.google.com/p/egit/issues/detail?id=52
Fxing this will make using Eclipse and Git together SO much nicer!
^ permalink raw reply
* Re: Removing options from build
From: Daniel Barkalow @ 2009-01-13 22:47 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: Thomas Rast, git
In-Reply-To: <1231884045.14181.36.camel@starfruit>
On Tue, 13 Jan 2009, R. Tyler Ballance wrote:
> On Tue, 2009-01-13 at 22:53 +0100, Thomas Rast wrote:
> > R. Tyler Ballance wrote:
> > > Besides a vigorous flogging, we're looking at other ways to prevent this
> > > sort of thing from happening again; the option we've settled on is to
> > > remove the "--force" flag from our internal build of v1.6.1
> > >
> > > I'm wondering if somebody could point me in the right direction to
> > > remove "--force" (safely) from the builtin-push.c and removing the
> > > "rebase" command (we've got no use for it, and would prefer it gone).
> >
> > IMHO your update (or pre-receive) hook should just disallow
> > non-fast-forward updates.
>
> Don't merges count as non-fast-forward updates? We generate merge
> commits with almost every merge, rarely do we actually have
> fast-forwards anymore (highly active repository)
Creating a merge is a non-fast-forward update, but sending the merge to a
repository that is currently at one of the parents is a fast-forward.
Hopefully, you're generating merge commits with merge, not with push. :)
> > This doesn't really address git-rebase, but it will disallow pushing a
> > "harmfully" rebased branch since those are by definition non-ff. Why
> > take away the option to correct a mistake in the last commit with 'git
> > rebase -i'?
>
> I'm a strong proponent of revision history only moving forward, I would
> much rather see a series of revert commits than having somebody who is
> inexperienced with the tools they're using muck about an jeopardize the
> stability of our central repository.
>
>
> Used correctly, both --force and `rebase` have good reason to exist in
> the Git codebase; they just haven't been used correctly, and proper
> bamboo to flog developers with will take a couple days to ship from
> Asia, so removing the options from our internal build is a lot easier
> and faster ;)
Denying non-fast-forward updates means that people can rebase, but if they
rebase anything that they've pushed (or anyone else has pushed), they
can't push.
You can't really disallow rebasing of private commits while still using
git; a user can always clone the upstream repository again, get diffs from
the repository where they don't like the history, apply them to the new
clone, and throw away the repository with the bad history. Or they can
call up a coworker, tell them what changes to make, commit, and push, and
then lose their work in a hard drive crash. People can always make the
excuse "My identical twin did stuff wrong, but I knocked him out before
he could push and did everything right." As long as they can't say "My
evil twin pushed the changes to the repository's evil twin, but I knocked
him out and destoryed the evil repository, and now we've got the good
repository."
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Fix Documentation typos surrounding the word 'handful'.
From: Johannes Schindelin @ 2009-01-13 22:45 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Junio C Hamano, Git List
In-Reply-To: <1231869591.19818.33.camel@ld0161-tx32>
Hi,
On Tue, 13 Jan 2009, Jon Loeliger wrote:
> On Tue, 2009-01-13 at 01:24 -0800, Junio C Hamano wrote:
> > Thanks, applied with fix from Markus and Sam.
>
> Thanks, Junio, for fixinf my lameness... :-)
Heh, I found this quote from Gerald M. Weinberg today:
The computer "doth make fools of us all," so that any fool without
the ability to share a laugh on himself will be unable to tolerate
programming for long.
Chuckles,
Dscho
^ permalink raw reply
* [PATCH] Git.pm: call Error::Simple() properly
From: Jay Soffian @ 2009-01-13 22:41 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Eric Wong, Junio C Hamano
The error message to Error::Simple() must be passed as a single argument.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
perl/Git.pm | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 8392a68..e9f8c9c 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1010,8 +1010,8 @@ sub _temp_cache {
my $temp_fd = \$TEMP_FILEMAP{$name};
if (defined $$temp_fd and $$temp_fd->opened) {
if ($TEMP_FILES{$$temp_fd}{locked}) {
- throw Error::Simple("Temp file with moniker '",
- $name, "' already in use");
+ throw Error::Simple("Temp file with moniker '" .
+ $name . "' already in use");
}
} else {
if (defined $$temp_fd) {
--
1.6.1.77.g81ea1
^ permalink raw reply related
* Re: [PATCH next] git-notes: fix printing of multi-line notes
From: Johannes Schindelin @ 2009-01-13 22:40 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: git, junio
In-Reply-To: <496CF21C.2050500@trolltech.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 556 bytes --]
Hi,
On Tue, 13 Jan 2009, Tor Arne Vestbø wrote:
> The line length was read from the same position every time,
> causing mangled output when printing notes with multiple lines.
>
> Also, adding new-line manually for each line ensures that we
> get a new-line between commits, matching git-log for commits
> without notes.
>
> Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
> ---
Patch looks good, so
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For extra browny points, you could add a test with multi-line notes.
Ciao,
Dscho
^ permalink raw reply
* Re: Removing options from build
From: Boyd Stephen Smith Jr. @ 2009-01-13 22:34 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1231885132.14181.38.camel@starfruit>
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
On Tuesday 2009 January 13 16:18:52 R. Tyler Ballance wrote:
>On Tue, 2009-01-13 at 16:06 -0600, Boyd Stephen Smith Jr. wrote:
>> receive.denyNonFastForwards
>> If set to true, git-receive-pack will deny a ref update which
>> is not a fast forward. Use this to prevent such an update via a
>> push, even if that push is forced.
>
>Looks good, thanks; sorry I missed it, didn't even think to look at the
>git-config(1) page for such an option.
I didn't really know about it until earlier this week. I was expecting to be
able to do a non-ff push to one of my repositories and it didn't work because
this was set "behind my back". (I'm not sure when it got added, but I don't
think the shared repositories I set up with git 1.4.4.4 had it, so I wasn't
expecting it.)
>I'm assuming this will actually cover the rebase -i case as well?
I don't know exactly what you mean. It prevents fast-forwards, so once a
commit is "visible" on one of your central branches, it won't ever go away.
(You can, of course, use git revert to undo it's changes.)
As others mentioned, now would be a good time to look at receive.denyDeletes
and/or a custom hook as well.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Removing options from build
From: R. Tyler Ballance @ 2009-01-13 22:18 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901131606.04634.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
On Tue, 2009-01-13 at 16:06 -0600, Boyd Stephen Smith Jr. wrote:
> On Tuesday 2009 January 13 15:43:22 R. Tyler Ballance wrote:
> >One of our developers "discovered" the --force option on `git push` and
> >used it without taking the appropriate care and hosed one of the project
> >branches we have running around in our central repository.
>
> Reflogs should let you recover from this.
>
> >Besides a vigorous flogging, we're looking at other ways to prevent this
> >sort of thing from happening again;
>
> receive.denyNonFastForwards
> If set to true, git-receive-pack will deny a ref update which
> is not a fast forward. Use this to prevent such an update via a
> push, even if that push is forced. This configuration variable
> is set when initializing a shared repository.
Looks good, thanks; sorry I missed it, didn't even think to look at the
git-config(1) page for such an option.
I'm assuming this will actually cover the rebase -i case as well?
Cheers
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Removing options from build
From: Boyd Stephen Smith Jr. @ 2009-01-13 22:10 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: Thomas Rast, git
In-Reply-To: <1231884045.14181.36.camel@starfruit>
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
On Tuesday 2009 January 13 16:00:45 R. Tyler Ballance wrote:
>On Tue, 2009-01-13 at 22:53 +0100, Thomas Rast wrote:
>> IMHO your update (or pre-receive) hook should just disallow
>> non-fast-forward updates.
>
>Don't merges count as non-fast-forward updates?
No. If there is a chain of parent links X ~> Y then updating a ref Y -> X is
a fast-forward.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Removing options from build
From: Björn Steinbrink @ 2009-01-13 22:07 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: Thomas Rast, git
In-Reply-To: <1231884045.14181.36.camel@starfruit>
On 2009.01.13 14:00:45 -0800, R. Tyler Ballance wrote:
> On Tue, 2009-01-13 at 22:53 +0100, Thomas Rast wrote:
> > R. Tyler Ballance wrote:
> > > Besides a vigorous flogging, we're looking at other ways to prevent this
> > > sort of thing from happening again; the option we've settled on is to
> > > remove the "--force" flag from our internal build of v1.6.1
> > >
> > > I'm wondering if somebody could point me in the right direction to
> > > remove "--force" (safely) from the builtin-push.c and removing the
> > > "rebase" command (we've got no use for it, and would prefer it gone).
> >
> > IMHO your update (or pre-receive) hook should just disallow
> > non-fast-forward updates.
>
> Don't merges count as non-fast-forward updates? We generate merge
> commits with almost every merge, rarely do we actually have
> fast-forwards anymore (highly active repository)
No, merges are "fast-forward". In rev-list terms:
git rev-list new_head..old_head ==> Empty
IOW: No commits are lost by the push.
Merges only add commits to the history, they don't remove anything.
Björn
^ permalink raw reply
* Re: How to pull remote branch with specified commit id?
From: Brad King @ 2009-01-13 21:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailinglist
In-Reply-To: <496C6234.9040903@viscovery.net>
Johannes Sixt wrote:
> Consider this: You accidentally push a branch with confidential data to a
> public repository. You notice it early, and quickly delete the branch
> using 'git push the-repo :refs/heads/that-branch'. At this time the
> objects with the confidential data are still lingering in the public
> repository. But with the current behavior noone can access them even if
> the SHA1 happens to be known.
Might a repack (perhaps an automatic one) put the object in a pack
(perhaps in a delta chain) that can be fetched through another ref?
-Brad
^ permalink raw reply
* Re: Removing options from build
From: Jakub Narebski @ 2009-01-13 22:05 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1231883002.14181.27.camel@starfruit>
"R. Tyler Ballance" <tyler@slide.com> writes:
> One of our developers "discovered" the --force option on `git push` and
> used it without taking the appropriate care and hosed one of the project
> branches we have running around in our central repository.
>
> Besides a vigorous flogging, we're looking at other ways to prevent this
> sort of thing from happening again; the option we've settled on is to
> remove the "--force" flag from our internal build of v1.6.1
>
> I'm wondering if somebody could point me in the right direction to
> remove "--force" (safely) from the builtin-push.c and removing the
> "rebase" command (we've got no use for it, and would prefer it gone).
First, the title (subject) of this email is misleading: it is about
your solution, and not about the problem you have (protecting against
"git push --force").
Second, there are two possible solutions: use receive.denyNonFastForwards
and perhaps also receive.denyDeletes (see git-config(1)) to forbid forced
pushes on server (target of push); removing '--force' is a client solution.
Or, better, use update or post-receive hook on server, forbidding
non-fastforward updates to selected set of 'stable' branches; you can
use contrib/hooks/update-paranoid for that.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Removing options from build
From: Boyd Stephen Smith Jr. @ 2009-01-13 22:06 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1231883002.14181.27.camel@starfruit>
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
On Tuesday 2009 January 13 15:43:22 R. Tyler Ballance wrote:
>One of our developers "discovered" the --force option on `git push` and
>used it without taking the appropriate care and hosed one of the project
>branches we have running around in our central repository.
Reflogs should let you recover from this.
>Besides a vigorous flogging, we're looking at other ways to prevent this
>sort of thing from happening again;
receive.denyNonFastForwards
If set to true, git-receive-pack will deny a ref update which
is not a fast forward. Use this to prevent such an update via a
push, even if that push is forced. This configuration variable
is set when initializing a shared repository.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ 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