* [PATCH 19/24] gitweb: Add startup delay to activity indicator for cache
From: Jakub Narebski @ 2010-12-06 23:11 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Junio C Hamano, demerphq, Aevar Arnfjord Bjarmason, Thomas Adam,
Jakub Narebski
In-Reply-To: <1291677069-6559-1-git-send-email-jnareb@gmail.com>
This adds support for [optional] startup delay to git_generating_data_html()
subroutine, which is used to provide "Generating..." page as activity
indicator when waiting for page to be generated if caching. If the data
(page contents) gets generated within $generating_options{'staryp_delay'}
seconds, the "Generating..." page won't get displayed.
This feature was created in response to complaint by Petr 'Pasky' Baudis'
about "Generating..." feature.
NOTE: This startup delay allows to use git_generating_data_html() also
for process generating data, assuming that die_error(), which turns of
capturing and which output (error page) is not cache, finishes within
startup delay.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch doesn't have equivalent in J.H. series, and is rather
extension of idea of progress indicator for (re)generating [cache]
data. It was inspired by comment by Petr 'Pasky' Baudis on #git IRC
channel that one doesn't want to have "Generating..." page to be shown
only to immediately vanish.
The additional advantage is that it solves problem with link that
leads to error page: die_error exits / ends request without generating
cache entry, so if "Generating..." is done also for process generating
data in background (perhaps it isn't true in J.H. series; I am not
sure about code flow there), then gitweb would endlessly show
"Generating..." page if it didn't wait and exited / ended request also
for die_error case.
The only difference compared to previous version of this series is that
git_generating_data_html is now marked as 'generating_info_is_safe'.
gitweb/gitweb.perl | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 181b85d..c974e79 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -357,11 +357,22 @@ our %cache_options = (
# is passed the following parameters: $cache instance, human-readable
# $key to current page, and filehandle $lock_fh to lockfile.
'generating_info' => \&git_generating_data_html,
+
+ # This enables/disables using 'generating_info' subroutine by process
+ # generating data, when not too stale data is not available (data is then
+ # generated in background). Because git_generating_data_html() includes
+ # initial delay (of 1 second by default), and we can assume that die_error
+ # finishes within this time, then generating error pages should be safe
+ # from infinite "Generating page..." loop.
+ 'generating_info_is_safe' => 1,
);
# You define site-wide options for "Generating..." page (if enabled) here
# (which means that $cache_options{'generating_info'} is set to coderef);
# override them with $GITWEB_CONFIG as necessary.
our %generating_options = (
+ # The delay before displaying "Generating..." page, in seconds. It is
+ # intended for "Generating..." page to be shown only when really needed.
+ 'startup_delay' => 1,
# The time between generating new piece of output to prevent from
# redirection before data is ready, i.e. time between printing each
# dot in activity indicator / progress info, in seconds.
@@ -3607,6 +3618,23 @@ sub git_generating_data_html {
return;
}
+ # Initial delay
+ if ($generating_options{'startup_delay'} > 0) {
+ eval {
+ local $SIG{ALRM} = sub { die "alarm clock restart\n" }; # NB: \n required
+ alarm $generating_options{'startup_delay'};
+ flock($lock_fh, LOCK_SH); # blocking readers lock
+ alarm 0;
+ };
+ if ($@) {
+ # propagate unexpected errors
+ die $@ if $@ !~ /alarm clock restart/;
+ } else {
+ # we got response within 'startup_delay' timeout
+ return;
+ }
+ }
+
my $title = "[Generating...] " . get_page_title();
# TODO: the following line of code duplicates the one
# in git_header_html, and it should probably be refactored.
--
1.7.3
^ permalink raw reply related
* [PATCH 05/24] gitweb/lib - Regenerate entry if the cache file has size of 0
From: Jakub Narebski @ 2010-12-06 23:10 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Junio C Hamano, demerphq, Aevar Arnfjord Bjarmason, Thomas Adam,
Jakub Narebski
In-Reply-To: <1291677069-6559-1-git-send-email-jnareb@gmail.com>
If the file representing cache entry has size 0 (in bytes), the cache
entry is considered invalid, regardless of its freshness, even if cache
expiration is turned off.
[jh: This is a quick, and thankfully easy, check to regenerate the
cache if the resulting file is of size 0. This *SHOULDN'T* happen,
but it is possible that it could and thus adding the check.]
Based-on-commit-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch is unchanged from previos version of this series.
It is inspired by commit 22eb7af (Gitweb - Regenerate the cache if the
resulting file has size of 0, 2010-09-23) on 'master' branch of
git/warthog9/gitweb.git repository on git.kernel.org
The "gitweb: File based caching layer (from git.kernel.org)" in
"Gitweb caching v7" by J.H. incudes the same test.
gitweb/lib/GitwebCache/SimpleFileCache.pm | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitweb/lib/GitwebCache/SimpleFileCache.pm b/gitweb/lib/GitwebCache/SimpleFileCache.pm
index 790383d..bf74f7c 100644
--- a/gitweb/lib/GitwebCache/SimpleFileCache.pm
+++ b/gitweb/lib/GitwebCache/SimpleFileCache.pm
@@ -310,6 +310,8 @@ sub is_valid {
# get its modification time
my $mtime = (stat(_))[9] # _ to reuse stat structure used in -f test
or die "Couldn't stat file '$path': $!";
+ # cache entry is invalid if it is size 0 (in bytes)
+ return 0 unless ((stat(_))[7] > 0);
# expire time can be set to never
my $expires_in = $self->get_expires_in();
--
1.7.3
^ permalink raw reply related
* [PATCH/RFC 22/24] gitweb: Support legacy options used by kernel.org caching engine
From: Jakub Narebski @ 2010-12-06 23:11 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Junio C Hamano, demerphq, Aevar Arnfjord Bjarmason, Thomas Adam,
Jakub Narebski
In-Reply-To: <1291677069-6559-1-git-send-email-jnareb@gmail.com>
Try to translate between config variables used by gitweb caching
patches[1] by John 'Warthog9' Hawley (J.H.) used, among others, by
git.kernel.org, and new %cache_options options, but only if the legacy
config variables were set in the config file.
Note that $cache_enable is *not* translated to $caching_enabled.
Footnotes:
~~~~~~~~~~
[1] See for example "Gitweb caching v7" thread on git mailing list:
http://thread.gmane.org/gmane.comp.version-control.git/160147
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch was not present in previous version of this series.
The drawback of this patch is that if any legacy config variable is set
in config file, then any change to %cache_options covering the same area
as legacy config variable would be ignored. I don't see a better
solution, unless we can somehow check if value of %cache_options was
changed via gitweb config file.
I wonder how useful this patch would be; do people using caching from
"Gitweb caching v7" (caching feom git.kernel.org) configure it, or do
they use default configuration?
gitweb/gitweb.perl | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5904d27..1521bf2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -284,6 +284,9 @@ our $caching_enabled = 0;
# Suggested mechanism:
# mv $cachedir $cachedir.flush && mkdir $cachedir && rm -rf $cachedir.flush
our $cache;
+
+# Legacy options configuring behavior of git.kernel.org caching
+our ($minCacheTime, $maxCacheTime, $cachedir, $backgroundCache, $maxCacheLife);
# You define site-wide cache options defaults here; override them with
# $GITWEB_CONFIG as necessary.
our %cache_options = (
@@ -1363,6 +1366,19 @@ sub configure_caching {
$cache ||= 'GitwebCache::FileCacheWithLocking';
eval "require $cache";
die $@ if $@;
+
+ # support for legacy config variables configuring cache behavior
+ # (those variables are/were used by caching engine by John Hawley,
+ # used among others by custom gitweb at http://git.kernel.org);
+ # it assumes that if those variables are defined, then we should
+ # use them - no provision is made for having both legacy variables
+ # and new %cache_options set in config file(s).
+ $cache_options{'cache_root'} = $cachedir if defined $cachedir;
+ $cache_options{'expires_min'} = $minCacheTime if defined $minCacheTime;
+ $cache_options{'expires_max'} = $maxCacheTime if defined $maxCacheTime;
+ $cache_options{'background_cache'} = $backgroundCache if defined $backgroundCache;
+ $cache_options{'max_lifetime'} = $maxCacheLife if defined $maxCacheLife;
+
$cache = $cache->new({
%cache_options,
#'cache_root' => '/tmp/cache',
--
1.7.3
^ permalink raw reply related
* [PATCH 15/24] gitweb/lib - Regenerate (refresh) cache in background
From: Jakub Narebski @ 2010-12-06 23:11 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Junio C Hamano, demerphq, Aevar Arnfjord Bjarmason, Thomas Adam,
Jakub Narebski
In-Reply-To: <1291677069-6559-1-git-send-email-jnareb@gmail.com>
This commit removes asymmetry in serving stale data (if stale data exists)
when regenerating cache in GitwebCache::FileCacheWithLocking. The process
that acquired exclusive (writers) lock, and is therefore selected to
be the one that (re)generates data to fill the cache, can now generate
data in background, while serving stale data.
Those background processes are daemonized, i.e. detached from the main
process (the one returning data or stale data). Otherwise there might be a
problem when gitweb is running as (part of) long-lived process, for example
from mod_perl or from FastCGI: it would leave unreaped children as zombies
(entries in process table). We don't want to wait for background process,
and we can't set $SIG{CHLD} to 'IGNORE' in gitweb to automatically reap
child processes, because this interferes with using
open my $fd, '-|', git_cmd(), 'param', ...
or die_error(...)
# read from <$fd>
close $fd
or die_error(...)
In the above code "close" for magic "-|" open calls waitpid... and we
would would die with "No child processes". Removing 'or die' would
possibly remove ability to react to other errors.
This feature can be enabled or disabled on demand via 'background_cache'
cache parameter. It is turned on by default.
The t9503 test got updated to test both case with background generation
enabled and case with background generation disabled.
Inspired-by-code-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Compared to previous version of this series ->_set_maybe_background
was extracted (refactored) from ->_compute_generic (in earlier version
it would be just ->compute). This hopefully makes code easier to
understand.
Differences to approach taken in "Gitweb caching v7" by J.H.
* It is made explicit that background generation depends on using
locking. It doesn't matter for J.H. series, as you canot turn off
using locking there.
* Forking (running generating process in background) is done only if
there is stale data to serve (and if background cache is turned on).
In J.H. series forking was done unconditionally, only generation or
exit depended on $backgroundCache (and technical/for debugging
$cacheDoFork).
* Locking is done before forking, as forking background process is done
only for the process regenerating cache.
* Daemonizes background process, detaching it from parent (using
setsid). This way whether main process is short-lived (gitweb as CGI)
or long-lived (mod_perl, PSGI or FastCGI), there would be no need to
wait and no zombies.
gitweb/gitweb.perl | 9 +++
gitweb/lib/GitwebCache/FileCacheWithLocking.pm | 64 ++++++++++++++++++++++--
t/t9503/test_cache_interface.pl | 40 ++++++++++++++-
3 files changed, 106 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 454766c..f202d6b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -335,6 +335,15 @@ our %cache_options = (
# Set it to -1 to always serve existing data if it exists,
# set it to 0 to turn off serving stale data - always wait.
'max_lifetime' => 5*60*60, # 5 hours
+
+ # This enables/disables background caching. If it is set to true value,
+ # caching engine would return stale data (if it is not older than
+ # 'max_lifetime' seconds) if it exists, and launch process if regenerating
+ # (refreshing) cache into the background. If it is set to false value,
+ # the process that fills cache must always wait for data to be generated.
+ # In theory this will make gitweb seem more responsive at the price of
+ # serving possibly stale data.
+ 'background_cache' => 1,
);
# Set to _initialized_ instance of GitwebCache::Capture compatibile capturing
# engine, i.e. one implementing ->new() constructor, and ->capture($code)
diff --git a/gitweb/lib/GitwebCache/FileCacheWithLocking.pm b/gitweb/lib/GitwebCache/FileCacheWithLocking.pm
index 1d32810..82e88f1 100644
--- a/gitweb/lib/GitwebCache/FileCacheWithLocking.pm
+++ b/gitweb/lib/GitwebCache/FileCacheWithLocking.pm
@@ -23,6 +23,7 @@ use warnings;
use File::Path qw(mkpath);
use Fcntl qw(:flock);
+use POSIX qw(setsid);
# ......................................................................
# constructor
@@ -70,21 +71,27 @@ use Fcntl qw(:flock);
# than it, serve stale data when waiting for cache entry to be
# regenerated (refreshed). Non-adaptive.
# Defaults to -1 (never expire / always serve stale).
+# * 'background_cache' (boolean)
+# This enables/disables regenerating cache in background process.
+# Defaults to true.
sub new {
my $class = shift;
my %opts = ref $_[0] ? %{ $_[0] } : @_;
my $self = $class->SUPER::new(\%opts);
- my ($max_lifetime);
+ my ($max_lifetime, $background_cache);
if (%opts) {
$max_lifetime =
$opts{'max_lifetime'} ||
$opts{'max_cache_lifetime'};
+ $background_cache = $opts{'background_cache'};
}
$max_lifetime = -1 unless defined($max_lifetime);
+ $background_cache = 1 unless defined($background_cache);
$self->set_max_lifetime($max_lifetime);
+ $self->set_background_cache($background_cache);
return $self;
}
@@ -95,7 +102,7 @@ sub new {
# http://perldesignpatterns.com/perldesignpatterns.html#AccessorPattern
# creates get_depth() and set_depth($depth) etc. methods
-foreach my $i (qw(max_lifetime)) {
+foreach my $i (qw(max_lifetime background_cache)) {
my $field = $i;
no strict 'refs';
*{"get_$field"} = sub {
@@ -146,6 +153,52 @@ sub _tempfile_to_path {
# ......................................................................
# interface methods
+sub _set_maybe_background {
+ my ($self, $key, $fetch_code, $set_code) = @_;
+
+ my $pid;
+ my (@result, @stale_result);
+
+ if ($self->{'background_cache'}) {
+ # try to retrieve stale data
+ @stale_result = $fetch_code->()
+ if $self->is_valid($key, $self->get_max_lifetime());
+
+ # fork if there is stale data, for background process
+ # to regenerate/refresh the cache (generate data)
+ $pid = fork() if (@stale_result);
+ }
+
+ if ($pid) {
+ ## forked and are in parent process
+ # reap child, which spawned grandchild process (detaching it)
+ waitpid $pid, 0;
+
+ } else {
+ ## didn't fork, or are in background process
+
+ # daemonize background process, detaching it from parent
+ # see also Proc::Daemonize, Apache2::SubProcess
+ if (defined $pid) {
+ ## in background process
+ POSIX::setsid(); # or setpgrp(0, 0);
+ fork() && CORE::exit(0);
+ }
+
+ @result = $set_code->();
+
+ if (defined $pid) {
+ ## in background process; parent will serve stale data
+
+ # lockfile will be automatically closed on exit,
+ # and therefore lockfile would be unlocked
+ CORE::exit(0);
+ }
+ }
+
+ return @result > 0 ? @result : @stale_result;
+}
+
sub _compute_generic {
my ($self, $key,
$get_code, $fetch_code, $set_code, $fetch_locked) = @_;
@@ -162,16 +215,19 @@ sub _compute_generic {
do {
open my $lock_fh, '+>', $lockfile
or die "Could't open lockfile '$lockfile': $!";
+
$lock_state = flock($lock_fh, LOCK_EX | LOCK_NB);
if ($lock_state) {
- # acquired writers lock
- @result = $set_code->();
+ ## acquired writers lock, have to generate data
+ @result = $self->_set_maybe_background($key, $fetch_code, $set_code);
# closing lockfile releases lock
close $lock_fh
or die "Could't close lockfile '$lockfile': $!";
} else {
+ ## didn't acquire writers lock, get stale data or wait for regeneration
+
# try to retrieve stale data
@result = $fetch_code->()
if $self->is_valid($key, $self->get_max_lifetime());
diff --git a/t/t9503/test_cache_interface.pl b/t/t9503/test_cache_interface.pl
index 8a52261..7f08863 100755
--- a/t/t9503/test_cache_interface.pl
+++ b/t/t9503/test_cache_interface.pl
@@ -24,9 +24,13 @@ diag("Testing '$INC{'GitwebCache/FileCacheWithLocking.pm'}'");
my $cache = new_ok('GitwebCache::FileCacheWithLocking', [ {
'max_lifetime' => 0, # turn it off
+ 'background_cache' => 0,
} ]);
isa_ok($cache, 'GitwebCache::SimpleFileCache');
+# compute can fork, don't generate zombies
+#local $SIG{CHLD} = 'IGNORE';
+
# Test that default values are defined
#
ok(defined $GitwebCache::SimpleFileCache::DEFAULT_CACHE_ROOT,
@@ -303,6 +307,9 @@ subtest 'parallel access' => sub {
my $stale_value = 'Stale Value';
subtest 'serving stale data when (re)generating' => sub {
+ # without background generation
+ $cache->set_background_cache(0);
+
$cache->set($key, $stale_value);
$call_count = 0;
$cache->set_expires_in(0); # expire now
@@ -312,12 +319,39 @@ subtest 'serving stale data when (re)generating' => sub {
my $data = cache_compute($cache, $key, \&get_value_slow);
print $data;
};
- ok(scalar(grep { $_ eq $stale_value } @output),
- 'stale data in at least one process when expired');
+ # returning stale data works
+ is_deeply(
+ [sort @output],
+ [sort ($value, $stale_value)],
+ 'no background: stale data returned by one process'
+ );
+
+ $cache->set_expires_in(-1); # never expire for next ->get
+ is($cache->get($key), $value,
+ 'no background: value got set correctly, even if stale data returned');
+
+
+ # with background generation
+ $cache->set_background_cache(1);
+
+ $cache->set($key, $stale_value);
+ $cache->set_expires_in(0); # set value is now expired
+ @output = parallel_run {
+ my $data = cache_compute($cache, $key, \&get_value_slow);
+ print $data;
+ };
+ # returning stale data works
+ is_deeply(
+ \@output,
+ [ ($stale_value) x 2 ],
+ 'background: stale data returned by both process when expired'
+ );
$cache->set_expires_in(-1); # never expire for next ->get
+ note('waiting for background process to have time to set data');
+ sleep $slow_time; # wait for background process to have chance to set data
is($cache->get($key), $value,
- 'value got set correctly, even if stale data returned');
+ 'background: value got set correctly by background process');
# $cache->set($key, $stale_value);
--
1.7.3
^ permalink raw reply related
* [PATCH 18/24] gitweb/lib - Configure running 'generating_info' when generating data
From: Jakub Narebski @ 2010-12-06 23:11 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Junio C Hamano, demerphq, Aevar Arnfjord Bjarmason, Thomas Adam,
Jakub Narebski
In-Reply-To: <1291677069-6559-1-git-send-email-jnareb@gmail.com>
Add a new 'generating_info_is_safe' cache option; if true, then
process generating data (one that acquired exclusive writer's lock)
would run 'generating_info' if there is no stale data and background
cache generation is enabled.
If function generating (or printing) exits, which leads to cache entry
not being generated (for gitweb this means that there are pages which
are not cached, i.e. error pages), and 'generating_info' also exits,
this could result in bad behavior. Therefore this new option is false
by default.
Updates t9503 test appropriately.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch was not present in previous version of this series.
This is one solution to the problem mentioned in commit message;
another is to use initial delay in "Generating..." page, as it is done
in next patch, and as it was done in previous version of this series.
gitweb/lib/GitwebCache/FileCacheWithLocking.pm | 17 ++++++++++++++---
t/t9503/test_cache_interface.pl | 1 +
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/gitweb/lib/GitwebCache/FileCacheWithLocking.pm b/gitweb/lib/GitwebCache/FileCacheWithLocking.pm
index 694c318..0823c55 100644
--- a/gitweb/lib/GitwebCache/FileCacheWithLocking.pm
+++ b/gitweb/lib/GitwebCache/FileCacheWithLocking.pm
@@ -80,26 +80,35 @@ use POSIX qw(setsid);
# instead), for other process (or bacground process). It is passed
# $cache instance, $key, and opened $lock_fh filehandle to lockfile.
# Unset by default (which means no activity indicator).
+# * 'generating_info_is_safe' (boolean)
+# If true, run 'generating_info' subroutine also in the project that
+# is generating data. This has effect only when 'background_cache'
+# is true (both 'background_cache' and 'generating_info_is_safe' must
+# be true for project generating data to run 'generating_info').
+# Defaults to false for safety.
sub new {
my $class = shift;
my %opts = ref $_[0] ? %{ $_[0] } : @_;
my $self = $class->SUPER::new(\%opts);
- my ($max_lifetime, $background_cache, $generating_info);
+ my ($max_lifetime, $background_cache, $generating_info, $gen_info_is_safe);
if (%opts) {
$max_lifetime =
$opts{'max_lifetime'} ||
$opts{'max_cache_lifetime'};
$background_cache = $opts{'background_cache'};
$generating_info = $opts{'generating_info'};
+ $gen_info_is_safe = $opts{'generating_info_is_safe'};
}
$max_lifetime = -1 unless defined($max_lifetime);
$background_cache = 1 unless defined($background_cache);
+ $gen_info_is_safe = 0 unless defined($gen_info_is_safe);
$self->set_max_lifetime($max_lifetime);
$self->set_background_cache($background_cache);
$self->set_generating_info($generating_info);
+ $self->set_generating_info_is_safe($gen_info_is_safe);
return $self;
}
@@ -110,7 +119,8 @@ sub new {
# http://perldesignpatterns.com/perldesignpatterns.html#AccessorPattern
# creates get_depth() and set_depth($depth) etc. methods
-foreach my $i (qw(max_lifetime background_cache generating_info)) {
+foreach my $i (qw(max_lifetime background_cache
+ generating_info generating_info_is_safe)) {
my $field = $i;
no strict 'refs';
*{"get_$field"} = sub {
@@ -214,7 +224,8 @@ sub _set_maybe_background {
# to regenerate/refresh the cache (generate data),
# or if main process would show progress indicator
$pid = fork()
- if (@stale_result || $self->{'generating_info'});
+ if (@stale_result ||
+ ($self->{'generating_info'} && $self->{'generating_info_is_safe'}));
}
if ($pid) {
diff --git a/t/t9503/test_cache_interface.pl b/t/t9503/test_cache_interface.pl
index 81f0b76..480cfbc 100755
--- a/t/t9503/test_cache_interface.pl
+++ b/t/t9503/test_cache_interface.pl
@@ -333,6 +333,7 @@ subtest 'serving stale data when (re)generating' => sub {
# with background generation
$cache->set_background_cache(1);
+ $cache->set_generating_info_is_safe(1);
$cache->set($key, $stale_value);
$cache->set_expires_in(0); # set value is now expired
--
1.7.3
^ permalink raw reply related
* [PATCH] completion: Add PS1 configuration for submodules
From: Scott Kyle @ 2010-12-06 23:22 UTC (permalink / raw)
To: git; +Cc: Scott Kyle
For those who often work on repositories with submodules, the dirty
indicator for unstaged changes will almost always show because development
is simultaneously happening on those submodules. The config option
diff.ignoreSubmodules is not appropriate for this use because it has larger
implications.
Signed-off-by: Scott Kyle <scott@appden.com>
---
contrib/completion/git-completion.bash | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 604fa79..539bcb1 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -37,7 +37,9 @@
# value, unstaged (*) and staged (+) changes will be shown next
# to the branch name. You can configure this per-repository
# with the bash.showDirtyState variable, which defaults to true
-# once GIT_PS1_SHOWDIRTYSTATE is enabled.
+# once GIT_PS1_SHOWDIRTYSTATE is enabled. You can also set
+# GIT_PS1_IGNORESUBMODULES to a value that git diff understands
+# to adjust the behavior of the dirty state indicator.
#
# You can also see if currently something is stashed, by setting
# GIT_PS1_SHOWSTASHSTATE to a nonempty value. If something is stashed,
@@ -286,7 +288,8 @@ __git_ps1 ()
elif [ "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" ]; then
if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
if [ "$(git config --bool bash.showDirtyState)" != "false" ]; then
- git diff --no-ext-diff --quiet --exit-code || w="*"
+ local ignore_submodules=${GIT_PS1_IGNORESUBMODULES+"--ignore-submodules=$GIT_PS1_IGNORESUBMODULES"}
+ git diff $ignore_submodules --no-ext-diff --quiet --exit-code || w="*"
if git rev-parse --quiet --verify HEAD >/dev/null; then
git diff-index --cached --quiet HEAD -- || i="+"
else
--
1.7.3.3.574.g98527
^ permalink raw reply related
* Re: Intermittent failures in t9119
From: Junio C Hamano @ 2010-12-07 0:00 UTC (permalink / raw)
To: Eric Wong; +Cc: David D. Kilzer, git
In-Reply-To: <20101206191055.GA9597@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> (2) Nobody uses the value from "Text Last Updated" field in practice, so
>> that bug has been unnoticed so far;
>>
>> (3) And it is not worth fixing it ;-)
>>
>> For now, I would suggest fixing the failing test to ignore the "Text Last
>> Updated" field while comparing, and if somebody is inclined to, we would
>> update the code to match what "svn info" does.
>
> Agreed on both points. I consider "git svn log" and "git svn info" to
> be reasonable approximations of svn behavior, not exact replicas.
> Exactly matching would be extremely difficult given variations between
> different svn versions, and also svn requiring network access while
> git svn does not.
Ok, here is a minimum patch to do that.
-- >8 --
Subject: t9119: do not compare "Text Last Updated" line from "svn info"
On the "Text Last Updated" line, "git svn info <file>" does not give the
timestamp of the commit that touched the path most recently, unlike "svn
info <file>". Do not expect the output from two commands to match on
these lines.
There was a "ptouch" attempt to transplant the timestamp from svn working
tree files to corresponding git working tree files, which mostly hid this
difference, but is made pointless now with this change. Remove the helper
function and calls to it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t9119-git-svn-info.sh | 106 +++++++++++++++--------------------------------
1 files changed, 34 insertions(+), 72 deletions(-)
diff --git a/t/t9119-git-svn-info.sh b/t/t9119-git-svn-info.sh
index f3f397c..ff19695 100755
--- a/t/t9119-git-svn-info.sh
+++ b/t/t9119-git-svn-info.sh
@@ -18,21 +18,14 @@ case $v in
;;
esac
-ptouch() {
- perl -w -e '
- use strict;
- use POSIX qw(mktime);
- die "ptouch requires exactly 2 arguments" if @ARGV != 2;
- my $text_last_updated = shift @ARGV;
- my $git_file = shift @ARGV;
- die "\"$git_file\" does not exist" if ! -e $git_file;
- if ($text_last_updated
- =~ /(\d{4})-(\d{2})-(\d{2}) (\d{2}):(\d{2}):(\d{2})/) {
- my $mtime = mktime($6, $5, $4, $3, $2 - 1, $1 - 1900);
- my $atime = $mtime;
- utime $atime, $mtime, $git_file;
- }
- ' "`svn_cmd info $2 | grep '^Text Last Updated:'`" "$1"
+# On the "Text Last Updated" line, "git svn info" does not return the
+# same value as "svn info" (i.e. the commit timestamp that touched the
+# path most recently); do not expect that field to match.
+test_cmp_info () {
+ sed -e '/^Text Last Updated:/d' "$1" >tmp.expect
+ sed -e '/^Text Last Updated:/d' "$2" >tmp.actual
+ test_cmp tmp.expect tmp.actual &&
+ rm -f tmp.expect tmp.actual
}
quoted_svnrepo="$(echo $svnrepo | sed 's/ /%20/')"
@@ -62,17 +55,13 @@ test_expect_success 'setup repository and import' '
cd gitwc &&
git svn init "$svnrepo" &&
git svn fetch
- ) &&
- ptouch gitwc/file svnwc/file &&
- ptouch gitwc/directory svnwc/directory &&
- ptouch gitwc/symlink-file svnwc/symlink-file &&
- ptouch gitwc/symlink-directory svnwc/symlink-directory
+ )
'
test_expect_success 'info' "
(cd svnwc; svn info) > expected.info &&
(cd gitwc; git svn info) > actual.info &&
- test_cmp expected.info actual.info
+ test_cmp_info expected.info actual.info
"
test_expect_success 'info --url' '
@@ -82,7 +71,7 @@ test_expect_success 'info --url' '
test_expect_success 'info .' "
(cd svnwc; svn info .) > expected.info-dot &&
(cd gitwc; git svn info .) > actual.info-dot &&
- test_cmp expected.info-dot actual.info-dot
+ test_cmp_info expected.info-dot actual.info-dot
"
test_expect_success 'info --url .' '
@@ -92,7 +81,7 @@ test_expect_success 'info --url .' '
test_expect_success 'info file' "
(cd svnwc; svn info file) > expected.info-file &&
(cd gitwc; git svn info file) > actual.info-file &&
- test_cmp expected.info-file actual.info-file
+ test_cmp_info expected.info-file actual.info-file
"
test_expect_success 'info --url file' '
@@ -102,13 +91,13 @@ test_expect_success 'info --url file' '
test_expect_success 'info directory' "
(cd svnwc; svn info directory) > expected.info-directory &&
(cd gitwc; git svn info directory) > actual.info-directory &&
- test_cmp expected.info-directory actual.info-directory
+ test_cmp_info expected.info-directory actual.info-directory
"
test_expect_success 'info inside directory' "
(cd svnwc/directory; svn info) > expected.info-inside-directory &&
(cd gitwc/directory; git svn info) > actual.info-inside-directory &&
- test_cmp expected.info-inside-directory actual.info-inside-directory
+ test_cmp_info expected.info-inside-directory actual.info-inside-directory
"
test_expect_success 'info --url directory' '
@@ -118,7 +107,7 @@ test_expect_success 'info --url directory' '
test_expect_success 'info symlink-file' "
(cd svnwc; svn info symlink-file) > expected.info-symlink-file &&
(cd gitwc; git svn info symlink-file) > actual.info-symlink-file &&
- test_cmp expected.info-symlink-file actual.info-symlink-file
+ test_cmp_info expected.info-symlink-file actual.info-symlink-file
"
test_expect_success 'info --url symlink-file' '
@@ -131,7 +120,7 @@ test_expect_success 'info symlink-directory' "
> expected.info-symlink-directory &&
(cd gitwc; git svn info symlink-directory) \
> actual.info-symlink-directory &&
- test_cmp expected.info-symlink-directory actual.info-symlink-directory
+ test_cmp_info expected.info-symlink-directory actual.info-symlink-directory
"
test_expect_success 'info --url symlink-directory' '
@@ -146,14 +135,13 @@ test_expect_success 'info added-file' "
git add added-file
) &&
cp gitwc/added-file svnwc/added-file &&
- ptouch gitwc/added-file svnwc/added-file &&
(
cd svnwc &&
svn_cmd add added-file > /dev/null
) &&
(cd svnwc; svn info added-file) > expected.info-added-file &&
(cd gitwc; git svn info added-file) > actual.info-added-file &&
- test_cmp expected.info-added-file actual.info-added-file
+ test_cmp_info expected.info-added-file actual.info-added-file
"
test_expect_success 'info --url added-file' '
@@ -163,7 +151,6 @@ test_expect_success 'info --url added-file' '
test_expect_success 'info added-directory' "
mkdir gitwc/added-directory svnwc/added-directory &&
- ptouch gitwc/added-directory svnwc/added-directory &&
touch gitwc/added-directory/.placeholder &&
(
cd svnwc &&
@@ -177,7 +164,7 @@ test_expect_success 'info added-directory' "
> expected.info-added-directory &&
(cd gitwc; git svn info added-directory) \
> actual.info-added-directory &&
- test_cmp expected.info-added-directory actual.info-added-directory
+ test_cmp_info expected.info-added-directory actual.info-added-directory
"
test_expect_success 'info --url added-directory' '
@@ -196,13 +183,12 @@ test_expect_success 'info added-symlink-file' "
ln -s added-file added-symlink-file &&
svn_cmd add added-symlink-file > /dev/null
) &&
- ptouch gitwc/added-symlink-file svnwc/added-symlink-file &&
(cd svnwc; svn info added-symlink-file) \
> expected.info-added-symlink-file &&
(cd gitwc; git svn info added-symlink-file) \
> actual.info-added-symlink-file &&
- test_cmp expected.info-added-symlink-file \
- actual.info-added-symlink-file
+ test_cmp_info expected.info-added-symlink-file \
+ actual.info-added-symlink-file
"
test_expect_success 'info --url added-symlink-file' '
@@ -221,13 +207,12 @@ test_expect_success 'info added-symlink-directory' "
ln -s added-directory added-symlink-directory &&
svn_cmd add added-symlink-directory > /dev/null
) &&
- ptouch gitwc/added-symlink-directory svnwc/added-symlink-directory &&
(cd svnwc; svn info added-symlink-directory) \
> expected.info-added-symlink-directory &&
(cd gitwc; git svn info added-symlink-directory) \
> actual.info-added-symlink-directory &&
- test_cmp expected.info-added-symlink-directory \
- actual.info-added-symlink-directory
+ test_cmp_info expected.info-added-symlink-directory \
+ actual.info-added-symlink-directory
"
test_expect_success 'info --url added-symlink-directory' '
@@ -235,11 +220,6 @@ test_expect_success 'info --url added-symlink-directory' '
= "$quoted_svnrepo/added-symlink-directory"
'
-# The next few tests replace the "Text Last Updated" value with a
-# placeholder since git doesn't have a way to know the date that a
-# now-deleted file was last checked out locally. Internally it
-# simply reuses the Last Changed Date.
-
test_expect_success 'info deleted-file' "
(
cd gitwc &&
@@ -249,13 +229,9 @@ test_expect_success 'info deleted-file' "
cd svnwc &&
svn_cmd rm --force file > /dev/null
) &&
- (cd svnwc; svn info file) |
- sed -e 's/^\(Text Last Updated:\).*/\1 TEXT-LAST-UPDATED-STRING/' \
- > expected.info-deleted-file &&
- (cd gitwc; git svn info file) |
- sed -e 's/^\(Text Last Updated:\).*/\1 TEXT-LAST-UPDATED-STRING/' \
- > actual.info-deleted-file &&
- test_cmp expected.info-deleted-file actual.info-deleted-file
+ (cd svnwc; svn info file) >expected.info-deleted-file &&
+ (cd gitwc; git svn info file) >actual.info-deleted-file &&
+ test_cmp_info expected.info-deleted-file actual.info-deleted-file
"
test_expect_success 'info --url file (deleted)' '
@@ -272,13 +248,9 @@ test_expect_success 'info deleted-directory' "
cd svnwc &&
svn_cmd rm --force directory > /dev/null
) &&
- (cd svnwc; svn info directory) |
- sed -e 's/^\(Text Last Updated:\).*/\1 TEXT-LAST-UPDATED-STRING/' \
- > expected.info-deleted-directory &&
- (cd gitwc; git svn info directory) |
- sed -e 's/^\(Text Last Updated:\).*/\1 TEXT-LAST-UPDATED-STRING/' \
- > actual.info-deleted-directory &&
- test_cmp expected.info-deleted-directory actual.info-deleted-directory
+ (cd svnwc; svn info directory) >expected.info-deleted-directory &&
+ (cd gitwc; git svn info directory) >actual.info-deleted-directory &&
+ test_cmp_info expected.info-deleted-directory actual.info-deleted-directory
"
test_expect_success 'info --url directory (deleted)' '
@@ -295,14 +267,9 @@ test_expect_success 'info deleted-symlink-file' "
cd svnwc &&
svn_cmd rm --force symlink-file > /dev/null
) &&
- (cd svnwc; svn info symlink-file) |
- sed -e 's/^\(Text Last Updated:\).*/\1 TEXT-LAST-UPDATED-STRING/' \
- > expected.info-deleted-symlink-file &&
- (cd gitwc; git svn info symlink-file) |
- sed -e 's/^\(Text Last Updated:\).*/\1 TEXT-LAST-UPDATED-STRING/' \
- > actual.info-deleted-symlink-file &&
- test_cmp expected.info-deleted-symlink-file \
- actual.info-deleted-symlink-file
+ (cd svnwc; svn info symlink-file) >expected.info-deleted-symlink-file &&
+ (cd gitwc; git svn info symlink-file) >actual.info-deleted-symlink-file &&
+ test_cmp_info expected.info-deleted-symlink-file actual.info-deleted-symlink-file
"
test_expect_success 'info --url symlink-file (deleted)' '
@@ -319,14 +286,9 @@ test_expect_success 'info deleted-symlink-directory' "
cd svnwc &&
svn_cmd rm --force symlink-directory > /dev/null
) &&
- (cd svnwc; svn info symlink-directory) |
- sed -e 's/^\(Text Last Updated:\).*/\1 TEXT-LAST-UPDATED-STRING/' \
- > expected.info-deleted-symlink-directory &&
- (cd gitwc; git svn info symlink-directory) |
- sed -e 's/^\(Text Last Updated:\).*/\1 TEXT-LAST-UPDATED-STRING/' \
- > actual.info-deleted-symlink-directory &&
- test_cmp expected.info-deleted-symlink-directory \
- actual.info-deleted-symlink-directory
+ (cd svnwc; svn info symlink-directory) >expected.info-deleted-symlink-directory &&
+ (cd gitwc; git svn info symlink-directory) >actual.info-deleted-symlink-directory &&
+ test_cmp_info expected.info-deleted-symlink-directory actual.info-deleted-symlink-directory
"
test_expect_success 'info --url symlink-directory (deleted)' '
^ permalink raw reply related
* Re: git fetch vs push, git am questions
From: Konstantin Khomoutov @ 2010-12-07 0:21 UTC (permalink / raw)
To: Konstantin Kivi; +Cc: git
In-Reply-To: <99351291667275@web152.yandex.ru>
On Mon, Dec 06, 2010 at 11:27:55PM +0300, Konstantin Kivi wrote:
[...]
> 1) Is it possible to achieve the same result with git fetch, as I have
> with git push. I have cloned a bare repository (2) from my repository
> (1) and I want fetch made in (2) get all info contained in (1) . I
> talk only about 'master' here. git push from (1) to (2) does the job,
> but git fetch in (1) updates only origin/master, and not master.
`git pull` does exactly that: fetch + merge (which should result in
fast-forward in your case).
> I also found that there is a notions of current branch in bare
> repository (master in my case), that stops my experiments of deleting
> master and making new master out of origin/master. How can I change
> current branch in bare repositry?
By re-writing the HEAD ref (this behaviour is documented in the man page
of the `git clone` command, see the "--branch" option for instance).
You can use the `git symbolic-ref` to update the HEAD ref.
[...]
P.S.
It's a bit strange you're playing with a bare repository in this way.
Usually a bare repository is supposed to be pushed to and pulled from,
not the other way round. Not that it's bad, but it may turn out you're
inventing a convoluted workflow when there may be a simpler solution.
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Nguyen Thai Ngoc Duy @ 2010-12-07 1:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlj42siu5.fsf@alter.siamese.dyndns.org>
On Tue, Dec 7, 2010 at 4:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
> +#define BRANCH_DELETION_LOG "DELETED-REFS"
> +
Should this special log be mentioned in git-update-ref.txt or
gitrepository-layout.txt?
--
Duy
^ permalink raw reply
* Re: interfacing M$-TFS
From: Neal Kreitzinger @ 2010-12-07 1:20 UTC (permalink / raw)
To: git
In-Reply-To: <20101203210139.GB14508@nibiru.local>
"Enrico Weigelt" <weigelt@metux.de> wrote in message
news:20101203210139.GB14508@nibiru.local...
>
> Hi folks,
>
>
> is there any way for directly interfacing M$-TFS (w/o its svn proxy) ?
>
> I'm currently working on an embedded linux project and my customer
> has a company wide policy to put everything into - please put on
> you intellectual seatbelt - M$ TFS.
>
> Needless to mention that TFS' VCS stuff is practically unusable,
> but some collegues still committing directly to TFS (haven't
> conviced them to switch over to git), and releases have to be
> put there, as QA folks dont know anything else.
>
> My current workflow is:
>
> #1: a main branch, frequently copied over TFS manually (;-o)
> #2: lots of topic branches which get rebased onto master
> #3: finished topic branches are rebased to latest master and
> then copied over to and committed in TFS
>
> Of course, that much manual work - especially with the need of
> checking out / locking invidual files in TFS - really suxx and
> wastes a lot of time. So I'm looking for way to:
>
> a) track remote branches from TFS
> b) push back changes into a TFS remote tracking branch
>
> Both should be possible from Linux side, using the native protocol
> (very unlikely that IT department can be convinced to install the
> svn proxy for TFS).
>
>
>
> thx
> --
> ----------------------------------------------------------------------
> Enrico Weigelt, metux IT service -- http://www.metux.de/
>
> phone: +49 36207 519931 email: weigelt@metux.de
> mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
> ----------------------------------------------------------------------
> Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
> ----------------------------------------------------------------------
I'm not familiar with TFS, but have you looked at the vendor-branch
methodology described in the git-rm manpage? It seems like it could cover
just about anything.
v/r,
Neal
^ permalink raw reply
* git-svn fails when svn.noMetaData is set
From: dclist @ 2010-12-07 2:24 UTC (permalink / raw)
To: git
Run on git version 1.7.3. Analyzed the source code using commit
0b0cd0e0a2.
Steps to reproduce
------------------
1. Set svn.noMetaData to true globally.
2. Invoke git svn clone on an svn repository
What happens
------------
Fatal error: "Not a SCALAR reference at /usr/lib/git-core/git-svn line 1457"
What I expect to happen
-----------------------
The clone to complete successfully
Analysis
--------
The problem seems to be line 1457, where the variable 'v' is
dereferenced and assigned a value --- $$v = $tmp ---- in combination
with line 118, where the value of the variable 'v' for the option
no-metadata is specified as a subroutine and, therefore, cannot be
assigned a value in the manner defined on line 1457. I believe the same
is true of other options that specify subroutines as their hash values.
^ permalink raw reply
* [BUG] yet another doc formatting problem
From: Jeff King @ 2010-12-07 5:07 UTC (permalink / raw)
To: git
When I build git-rm.1, some of the headings look odd. For example:
Using git commit -a""
If you intend that your next commit should record...
...
Using git add -A""
When accepting a new code drop for a vendor branch
Note the funny double-space and the weird "" at the end. I get the same
thing from "git show origin/man:man1/git-rm.1 | nroff -man".
The source looks like this:
$ git grep -A1 Using..git.commit git-rm.txt
git-rm.txt:Using "git commit -a"
git-rm.txt-~~~~~~~~~~~~~~~~~~~~~
which looks sane to me. The generated xml also looks OK to me:
$ grep Using..git.commit git-rm.xml
<title>Using "git commit -a"</title>
But the resulting roff doesn't:
$ grep Using..git.commit git-rm.1
.SS "Using "git commit \-a""
which looks like a quoting error to me, which implies a bug in docbook.
I guess we can hack around it with some XSL magic, but I am tempted to
do the simple:
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 71e3d9f..8ee559b 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -89,8 +89,8 @@ the paths that have disappeared from the filesystem. However,
depending on the use case, there are several ways that can be
done.
-Using "git commit -a"
-~~~~~~~~~~~~~~~~~~~~~
+Using git commit -a
+~~~~~~~~~~~~~~~~~~~
If you intend that your next commit should record all modifications
of tracked files in the working tree and record all removals of
files that have been removed from the working tree with `rm`
@@ -98,8 +98,8 @@ files that have been removed from the working tree with `rm`
automatically notice and record all removals. You can also have a
similar effect without committing by using `git add -u`.
-Using "git add -A"
-~~~~~~~~~~~~~~~~~~
+Using git add -A
+~~~~~~~~~~~~~~~~
When accepting a new code drop for a vendor branch, you probably
want to record both the removal of paths and additions of new paths
as well as modifications of existing paths.
-Peff
^ permalink raw reply related
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Junio C Hamano @ 2010-12-07 6:28 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <AANLkTikbsyFUzZeu8R6yAND6spV6OnvYL08gYZ+ZgJCh@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Tue, Dec 7, 2010 at 4:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> +#define BRANCH_DELETION_LOG "DELETED-REFS"
>> +
>
> Should this special log be mentioned in git-update-ref.txt or
> gitrepository-layout.txt?
Perhaps, but I wasn't sure if this patch itself is a good idea to begin
with. Not the problem it tries to solve, but its approach.
For example, this cannot be shown with "reflog show" or "log -g" due to
the way these frontends locate the reflog file to read (the logic wants to
have an underlying ref).
^ permalink raw reply
* Re: git diff --summary only seems to work when combined with --stat
From: demerphq @ 2010-12-07 6:53 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git
In-Reply-To: <20101206210304.GA9735@burratino>
On 6 December 2010 22:03, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Yves,
>
> demerphq wrote:
>
>> It seems like the --summary option only works in combination --stat.
>>
>> It doesn't seem to work if I use it by itself, nor in combination with
>> --name-status or --num-stat. And depending on the order, it either
>> does nothing, or causes a usage note.
>
> It is tricky, but as you noticed --summary is not actually about the
> diffstat. --summary affects the output summarizing new files and
> renamed files.
>
> Example:
>
> $ git diff --summary v1.7.2..v1.7.3
> delete mode 100644 Documentation/RelNotes-1.5.0.1.txt
> delete mode 100644 Documentation/RelNotes-1.5.0.2.txt
> [...]
>
>> $ git diff --name-status --sumary HEAD^
>> usage: git diff <options> <rev>{0,2} -- <path>*
>
> There is an 'm' missing here. :)
Thanks for your reply. It turns out that was a mis-paste. I tried both
splelings of summary. ;-)
And none of them produce output.
$ git diff --summary HEAD^..HEAD
$ git diff --summary HEAD^^..HEAD
$ git diff --summary HEAD..HEAD^
$ git diff --summary HEAD^
So why does it work for you but not for me?
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: git diff --summary only seems to work when combined with --stat
From: demerphq @ 2010-12-07 6:55 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git
In-Reply-To: <AANLkTinuQoJLfDq8HhUd=FLoqosVD23MU6ch6Ea2iVSJ@mail.gmail.com>
On 7 December 2010 07:53, demerphq <demerphq@gmail.com> wrote:
> On 6 December 2010 22:03, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Hi Yves,
>>
>> demerphq wrote:
>>
>>> It seems like the --summary option only works in combination --stat.
>>>
>>> It doesn't seem to work if I use it by itself, nor in combination with
>>> --name-status or --num-stat. And depending on the order, it either
>>> does nothing, or causes a usage note.
>>
>> It is tricky, but as you noticed --summary is not actually about the
>> diffstat. --summary affects the output summarizing new files and
>> renamed files.
>>
>> Example:
>>
>> $ git diff --summary v1.7.2..v1.7.3
>> delete mode 100644 Documentation/RelNotes-1.5.0.1.txt
>> delete mode 100644 Documentation/RelNotes-1.5.0.2.txt
>> [...]
>>
>>> $ git diff --name-status --sumary HEAD^
>>> usage: git diff <options> <rev>{0,2} -- <path>*
>>
>> There is an 'm' missing here. :)
>
> Thanks for your reply. It turns out that was a mis-paste. I tried both
> splelings of summary. ;-)
>
> And none of them produce output.
>
> $ git diff --summary HEAD^..HEAD
> $ git diff --summary HEAD^^..HEAD
> $ git diff --summary HEAD..HEAD^
> $ git diff --summary HEAD^
>
> So why does it work for you but not for me?
Ah. Not enough coffee. It "doesnt work" because I am not adding or
renaming a file here?
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: [BUG] yet another doc formatting problem
From: Michael J Gruber @ 2010-12-07 8:42 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20101207050737.GA32485@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 07.12.2010 06:07:
> When I build git-rm.1, some of the headings look odd. For example:
>
> Using git commit -a""
> If you intend that your next commit should record...
> ...
> Using git add -A""
> When accepting a new code drop for a vendor branch
>
> Note the funny double-space and the weird "" at the end. I get the same
> thing from "git show origin/man:man1/git-rm.1 | nroff -man".
>
> The source looks like this:
>
> $ git grep -A1 Using..git.commit git-rm.txt
> git-rm.txt:Using "git commit -a"
> git-rm.txt-~~~~~~~~~~~~~~~~~~~~~
>
> which looks sane to me. The generated xml also looks OK to me:
>
> $ grep Using..git.commit git-rm.xml
> <title>Using "git commit -a"</title>
>
> But the resulting roff doesn't:
>
> $ grep Using..git.commit git-rm.1
> .SS "Using "git commit \-a""
>
> which looks like a quoting error to me, which implies a bug in docbook.
>
> I guess we can hack around it with some XSL magic, but I am tempted to
> do the simple:
>
> diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
> index 71e3d9f..8ee559b 100644
> --- a/Documentation/git-rm.txt
> +++ b/Documentation/git-rm.txt
> @@ -89,8 +89,8 @@ the paths that have disappeared from the filesystem. However,
> depending on the use case, there are several ways that can be
> done.
>
> -Using "git commit -a"
> -~~~~~~~~~~~~~~~~~~~~~
> +Using git commit -a
> +~~~~~~~~~~~~~~~~~~~
> If you intend that your next commit should record all modifications
> of tracked files in the working tree and record all removals of
> files that have been removed from the working tree with `rm`
> @@ -98,8 +98,8 @@ files that have been removed from the working tree with `rm`
> automatically notice and record all removals. You can also have a
> similar effect without committing by using `git add -u`.
>
> -Using "git add -A"
> -~~~~~~~~~~~~~~~~~~
> +Using git add -A
> +~~~~~~~~~~~~~~~~
> When accepting a new code drop for a vendor branch, you probably
> want to record both the removal of paths and additions of new paths
> as well as modifications of existing paths.
>
> -Peff
Couple'o'things goin' on here ;)
First of all, we shouldn't use a literal " to denote a "quotation". Just
like in HTML, this may or may not work. Typographically, the outcome was
*always* wrong. The proper way in asciidoc is surrounding the
``quotation'' by double backticks and double ticks. Doing it right in
git-rm.txt will lead to proper nroff and html outputs, e.g.:
Using “git commit -a”
Of course, literal " works in most place - well, save the fact that it
never really works because it never produces typographically correct
output. Am I repeating myself? ;)
Here, a literal " in asciidoc ends up as a literal " in html and xml.
Any browser groks it in a place like that, producing correct output -
well, save the fact that...
docbook (translating xml to nroff) does not grok it. Now that is a
surprise... Pleeease, someone get me straight asciidoc to nroff!
On a side note, looking at origin/man I get the impression that these
subheaders were always wrong.
So, in summary, we should really ``quote'' things properly, but this
would need to be done consistently, because a mix of new
(typographhically correct) quotes and old ones looks even worse. If we
really want to go that route I'd volunteer to do things one by one.
Actually, it seems we've been partially going that route already, using
{tilde}, {apostrophe} etc.
Michael
^ permalink raw reply
* [PATCH] git-rm.txt: Fix quoting
From: Michael J Gruber @ 2010-12-07 9:07 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In-Reply-To: <4CFDF388.6060907@drmicha.warpmail.net>
Literal " produces typographically incorrect quotations, but "works" in
most circumstances. In the subheadings of git-rm.txt, it "works" for the
html backend but not for the docbook conversion to nroff: double "" and
spurious double spaces appear in the output.
Replace "incorrect" quotations by ``correct'' ones, and fix other
"quotations" which are really `code fragments`.
This should make git-rm.txt "-clean.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
We still have a lingering inconsistency for denoting code fragments.
Single backticks merely are a literal monospaced environment; html outputcolors
this, nroff does not indicate it at all. I'm staying consistent with the
surrounding text here.
Documentation/git-rm.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 71e3d9f..dd61ebd 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -89,7 +89,7 @@ the paths that have disappeared from the filesystem. However,
depending on the use case, there are several ways that can be
done.
-Using "git commit -a"
+Using ``git commit -a''
~~~~~~~~~~~~~~~~~~~~~
If you intend that your next commit should record all modifications
of tracked files in the working tree and record all removals of
@@ -98,7 +98,7 @@ files that have been removed from the working tree with `rm`
automatically notice and record all removals. You can also have a
similar effect without committing by using `git add -u`.
-Using "git add -A"
+Using ``git add -A''
~~~~~~~~~~~~~~~~~~
When accepting a new code drop for a vendor branch, you probably
want to record both the removal of paths and additions of new paths
@@ -111,8 +111,8 @@ tree using this command:
git ls-files -z | xargs -0 rm -f
----------------
-and then "untar" the new code in the working tree. Alternately
-you could "rsync" the changes into the working tree.
+and then `untar` the new code in the working tree. Alternately
+you could `rsync` the changes into the working tree.
After that, the easiest way to record all removals, additions, and
modifications in the working tree is:
--
1.7.3.2.660.g7cc83
^ permalink raw reply related
* Re: [PATCH] completion: Add PS1 configuration for submodules
From: SZEDER Gábor @ 2010-12-07 9:40 UTC (permalink / raw)
To: Scott Kyle; +Cc: git
In-Reply-To: <1291677763-55385-1-git-send-email-scott@appden.com>
Hi Scott,
On Mon, Dec 06, 2010 at 03:22:43PM -0800, Scott Kyle wrote:
> For those who often work on repositories with submodules, the dirty
> indicator for unstaged changes will almost always show because development
> is simultaneously happening on those submodules. The config option
> diff.ignoreSubmodules is not appropriate for this use because it has larger
> implications.
>
> Signed-off-by: Scott Kyle <scott@appden.com>
> ---
> contrib/completion/git-completion.bash | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 604fa79..539bcb1 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -37,7 +37,9 @@
> # value, unstaged (*) and staged (+) changes will be shown next
> # to the branch name. You can configure this per-repository
> # with the bash.showDirtyState variable, which defaults to true
> -# once GIT_PS1_SHOWDIRTYSTATE is enabled.
> +# once GIT_PS1_SHOWDIRTYSTATE is enabled. You can also set
> +# GIT_PS1_IGNORESUBMODULES to a value that git diff understands
> +# to adjust the behavior of the dirty state indicator.
git diff "understands" a lot of things, therefore I'd like to be a bit
more specific here by mentioning the --ignore-submodules= option:
+# once GIT_PS1_SHOWDIRTYSTATE is enabled. You can also set
+# GIT_PS1_IGNORESUBMODULES to a value that git diff
+# --ignore-submodules= understands to adjust the behavior of the
+# dirty state indicator.
But it might be just me being unfamiliar with submodules. Otherwise
it looks good and reasonable to me.
> #
> # You can also see if currently something is stashed, by setting
> # GIT_PS1_SHOWSTASHSTATE to a nonempty value. If something is stashed,
> @@ -286,7 +288,8 @@ __git_ps1 ()
> elif [ "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" ]; then
> if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
> if [ "$(git config --bool bash.showDirtyState)" != "false" ]; then
> - git diff --no-ext-diff --quiet --exit-code || w="*"
> + local ignore_submodules=${GIT_PS1_IGNORESUBMODULES+"--ignore-submodules=$GIT_PS1_IGNORESUBMODULES"}
> + git diff $ignore_submodules --no-ext-diff --quiet --exit-code || w="*"
> if git rev-parse --quiet --verify HEAD >/dev/null; then
> git diff-index --cached --quiet HEAD -- || i="+"
> else
> --
> 1.7.3.3.574.g98527
>
>
^ permalink raw reply
* Re: [PATCH] describe: Don’t look up commits with --exact-match
From: SZEDER Gábor @ 2010-12-07 9:58 UTC (permalink / raw)
To: Anders Kaseorg
Cc: Jonathan Nieder, Junio C Hamano, git, Kirill Smelkov, Thomas Rast
In-Reply-To: <alpine.DEB.2.02.1012061159500.23348@dr-wily.mit.edu>
Hi,
On Mon, Dec 06, 2010 at 12:28:59PM -0500, Anders Kaseorg wrote:
> This makes ‘git describe --exact-match HEAD’ about 15 times faster on
> a cold cache (2.3s instead of 35s) in a linux-2.6 repository with many
> packed tags. That’s a huge win for the interactivity of the __git_ps1
> shell prompt helper.
I wanted to give it a try to see the performance improvements in the
bash prompt for myself, but couldn't get to it so far. However,
glancing through the logic finding out the current branch in
__git_ps1, it seems that git describe is only run when git
symbolic-ref HEAD failed, i.e. when on a detached head. So the
performance improvement in the shell prompt is only there when on a
detached head (and with lots of tags), right? If so, then I'd like to
have "when on a detached head" appended to the commit message.
Best,
Gábor
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Nguyen Thai Ngoc Duy @ 2010-12-07 11:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmxoiqeoq.fsf@alter.siamese.dyndns.org>
On Tue, Dec 7, 2010 at 1:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> On Tue, Dec 7, 2010 at 4:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> +#define BRANCH_DELETION_LOG "DELETED-REFS"
>>> +
>>
>> Should this special log be mentioned in git-update-ref.txt or
>> gitrepository-layout.txt?
>
> Perhaps, but I wasn't sure if this patch itself is a good idea to begin
> with. Not the problem it tries to solve, but its approach.
>
> For example, this cannot be shown with "reflog show" or "log -g" due to
> the way these frontends locate the reflog file to read (the logic wants to
> have an underlying ref).
>
I think you have thought of this. What's wrong with keeping reflog
when a branch is removed and appending "delete" line to the said
reflog? I don't know how reflogs are managed, but those reflogs
without associated branch will (or should) be cleaned when they are
expired.
I stick with this idea because I also want to archive old branches and
am thinking those reflogs ending with "archive" line will be kept
forever, or until I feel like digging up them again.
--
Duy
^ permalink raw reply
* Re: [PATCH] completion: Add PS1 configuration for submodules
From: Ævar Arnfjörð Bjarmason @ 2010-12-07 12:15 UTC (permalink / raw)
To: Scott Kyle; +Cc: git
In-Reply-To: <1291677763-55385-1-git-send-email-scott@appden.com>
On Tue, Dec 7, 2010 at 00:22, Scott Kyle <scott@appden.com> wrote:
> For those who often work on repositories with submodules, the dirty
> indicator for unstaged changes will almost always show because development
> is simultaneously happening on those submodules. The config option
> diff.ignoreSubmodules is not appropriate for this use because it has larger
> implications.
Wouldn't it be a lot better to instead add support for showing
submodule dirtyness as distinct from the main tree's dirtyness? Then
you could easily spot if you had either your tree / submodule tree
changes, without just ignoring them.
^ permalink raw reply
* Re: git fetch vs push, git am questions
From: Konstantin Kivi @ 2010-12-07 12:31 UTC (permalink / raw)
To: Konstantin Khomoutov; +Cc: git
In-Reply-To: <20101207002104.GG3264@localhost.localdomain>
07.12.10, 03:21, "Konstantin Khomoutov" <flatworm@users.sourceforge.net>:
> `git pull` does exactly that: fetch + merge (which should result in
> fast-forward in your case).
pull does not work on bare repos.
> > I also found that there is a notions of current branch in bare repository
> > How can I change current branch in bare repositry?
I think I will understand things better if I get what is 'current branch' for bare repository
and how to change it
> By re-writing the HEAD ref (this behaviour is documented in the man page
> of the `git clone` command, see the "--branch" option for instance).
The repository already exists, so git-clone will not help
> You can use the `git symbolic-ref` to update the HEAD ref.
>
Do you mean something like
git symbolic-ref master origin/master ?
> [...]
>
> P.S.
> It's a bit strange you're playing with a bare repository in this way.
> Usually a bare repository is supposed to be pushed to and pulled from,
> not the other way round. Not that it's bad, but it may turn out you're
> inventing a convoluted workflow when there may be a simpler solution.
Yes, I see that push is easier, I only want to be sure I have full control on what is going on.
--
С уважением, Константин Киви
^ permalink raw reply
* Re: git reset and ctime
From: Drew Northup @ 2010-12-07 15:14 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: ghazel, git, Junio C Hamano
In-Reply-To: <20101206175102.GC6272@burratino>
On Mon, 2010-12-06 at 11:51 -0600, Jonathan Nieder wrote:
> Drew Northup wrote:
> > On Fri, 2010-12-03 at 18:51 -0600, Jonathan Nieder wrote:
>
> >> Interesting. Setting "[core] trustctime = false" in the repository
> >> configuration could be a good solution (no performance downside I can
> >> think of).
> >
> > It is worth noting that many file-based backup systems which do "online"
> > backups (such as in use where I work) restore the atime by default at
> > the expense of the ctime (logic being that the atime may have had value
> > and the ctime changes either way--which may or may not be true) on unix
> > style filesystems.
>
> So have you tried putting "[core] trustctime = false" in /etc/gitconfig?
> This is exactly what the setting is for, after all.
I hadn't yet, but it works like a charm.
> Ideas for making this easier to find (FAQ on the git wiki? advice from
> porcelain when ctime-only changes happen?) would be welcome, of course.
I'll have a look over that way a bit later.
I'm also going to have to have a look at the src.rpm for this particular
packaging of git and find out why it didn't create a
skeleton /etc/gitconfig (without much in it) in the postinstall script.
(I'm using the Dag Wieers / rpmforge one on my desktop.) It makes a lot
more sense to send along a patch then randomly demand that he change
it--he may have had a decent reason for not doing so.
--
-Drew Northup N1XIM
AKA RvnPhnx on OPN
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: path/to/some/file: needs update
From: Drew Northup @ 2010-12-07 15:23 UTC (permalink / raw)
To: Ben Walton; +Cc: Patrick Doyle, Matthieu Moy, git
In-Reply-To: <1291668405-sup-122@pinkfloyd.chass.utoronto.ca>
On Mon, 2010-12-06 at 15:47 -0500, Ben Walton wrote:
> Excerpts from Patrick Doyle's message of Sun Dec 05 19:44:32 -0500 2010:
>
> > I just checked. The box they were using is an RHEL 5 box that has
> > 1.5.5.6 installed on it. Perhaps it's time to upgrade their git.
> > I'll go see what repo I need to add to RHEL to get a more recent
> > git.
>
> I maintain a local set of 1.7.x rpms for git that are built for rhel5
> here. I'm happy to share if it would help.
>
> Thanks
> -Ben
Dag Wieers (rpmforge) maintains a decent git package for RHEL5 as well.
--
-Drew Northup N1XIM
AKA RvnPhnx on OPN
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Michael J Gruber @ 2010-12-07 15:25 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <AANLkTinDyix3KEdLLGJEWQ8X+a3zQZOAiTh2mLf5wuvQ@mail.gmail.com>
Nguyen Thai Ngoc Duy venit, vidit, dixit 07.12.2010 12:37:
> On Tue, Dec 7, 2010 at 1:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>
>>> On Tue, Dec 7, 2010 at 4:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> +#define BRANCH_DELETION_LOG "DELETED-REFS"
>>>> +
>>>
>>> Should this special log be mentioned in git-update-ref.txt or
>>> gitrepository-layout.txt?
>>
>> Perhaps, but I wasn't sure if this patch itself is a good idea to begin
>> with. Not the problem it tries to solve, but its approach.
>>
>> For example, this cannot be shown with "reflog show" or "log -g" due to
>> the way these frontends locate the reflog file to read (the logic wants to
>> have an underlying ref).
>>
>
> I think you have thought of this. What's wrong with keeping reflog
> when a branch is removed and appending "delete" line to the said
> reflog? I don't know how reflogs are managed, but those reflogs
> without associated branch will (or should) be cleaned when they are
> expired.
The problem is the following:
Say, you delete a branch and its reflog is kept (with a "delete" line
appended).
Then you create a new branch under the same name. What is supposed to
happen to the reflog? If you simply append, then old (unrelated) entries
will not expire through the imagined "expire branch reflogs" mechanism.
Now, you rename that branch. We should really split the reflog in two
now, keeping the old name for the old parts and moving only the newer
parts to the reflog with the new name.
This is all workable in principle but hints at a design flaw.
Maybe it's easier to teach "git reflog" about "DELETED_REFS"?
Michael
^ 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