* The lifecycle of a patch and the maintainer involvement
From: Junio C Hamano @ 2009-01-25 20:35 UTC (permalink / raw)
To: Brent Goodrick; +Cc: Johannes Schindelin, Daniel Barkalow, Mike Ralphson, git
In-Reply-To: <18811.32772.728276.923430@hungover.brentg.com>
Brent Goodrick <bgoodr@gmail.com> writes:
> While I'm at it, what is the standard procedure for submitting git
> patches for review once I've cooked up and validated it on my end? I'm
> guessing posting the patch into this mailing list is part of the
> answer to that question.
Yes, a guideline is in Documentation/SubmittingPatches for the initial
submission. After that, the lifecycle of a patch submitted on the list
goes like this:
(1) A patch is shown to the list participants.
(2) People may like it, or may have issues with it, and responds with
their comments describing problems, suggestions for improvements,
etc. People who are not interested in the topic may stay silent.
(3) The original author responds with updated patch. Sometimes people
who commented on in step 2 may even send "here is how I would do this
one; don't you think this is better?", and the original author may
say "Yeah, let's use yours instead".
(4) After steps 2 and 3 repeats zero or more times, the latest patch may
become one that everyone likes, or at least nobody has trouble with
inclusion. The author sends such a patch saying "this is meant for
inclusion based on discussion and refinements in these threads...".
(5) The maintainer picks it up when it looks polished enough.
Your patch may appear in the periodical "What's cooking" or "What's in"
summary with zero iteration of steps 2 and 3 if it is obvious enough.
I act as just one of the list participant during steps 1-3. I may stay
silent during this period but that only means the topic is not interesting
to me and nothing more. It does not mean that the topic has no chance of
getting included.
I act as the maintainer for steps 4 and 5. If you do not hear from me
after step 4, then I am either being lazy, busy, or sick, or the patch got
lost in the noise and I need a reminder. Note that I may reject or ask
further refinement at step 4 to ensure overall quality throughout the
system even in areas I am not interested in and didn't say anything during
steps 1-3.
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Junio C Hamano @ 2009-01-25 20:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Jakub Narebski, git
In-Reply-To: <alpine.DEB.1.00.0901251622310.14855@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So maybe I answered my question myself:
>
> merge parents $sha1 [$sha1...] original $sha1 $msg
When you are reparenting, how would original commit get in the picture?
You wouldn't want the resulting merge to claim it merged X (which would be
what's in original's commit log) when in fact it now merged Y because the
user reparented it, would you?
^ permalink raw reply
* Re: [PATCH v1 0/3] Introduce config variable "diff.primer"
From: Junio C Hamano @ 2009-01-25 20:35 UTC (permalink / raw)
To: Keith Cascio; +Cc: Jeff King, Johannes Schindelin, git
In-Reply-To: <1232904657-31831-1-git-send-email-keith@cs.ucla.edu>
Keith Cascio <keith@cs.ucla.edu> writes:
> Future work: Extend the gitattributes mechanism so it supports
> all [diff] config variables, including e.g. diff.mnemonicprefix
> and diff.primer.
I am puzzled.
The gitattributes mechanism is about per-path settings, but I do not think
a mnemonicprefix that is per-path makes much sense.
^ permalink raw reply
* Re: [PATCH 1/3] git-svn: add --ignore-paths option for fetching
From: Sverre Rabbelier @ 2009-01-25 20:41 UTC (permalink / raw)
To: Vitaly _Vi Shukela; +Cc: trast, git
In-Reply-To: <1232912944-27076-1-git-send-email-public_vi@tut.by>
On Sun, Jan 25, 2009 at 20:49, Vitaly _Vi Shukela <public_vi@tut.by> wrote:
>
> Signed-off-by: Vitaly "_Vi" Shukela <public_vi@tut.by>
You still did not explain _in your commit message_ why it would be
useful to have, which is what Thomas asked for ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v1 0/3] Introduce config variable "diff.primer"
From: Keith Cascio @ 2009-01-25 20:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr62rcee5.fsf@gitster.siamese.dyndns.org>
On Sun, 25 Jan 2009, Junio C Hamano wrote:
> I am puzzled.
>
> The gitattributes mechanism is about per-path settings, but I do not think a
> mnemonicprefix that is per-path makes much sense.
That was just an example (perhaps poorly chosen). What I meant to suggest is
making gitattributes consistent with gitconfig WRT at least the [diff] section.
But maybe that's not appropriate. Thanks for the insight.
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Johannes Schindelin @ 2009-01-25 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, Jakub Narebski, git
In-Reply-To: <7vwscjceec.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 25 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > So maybe I answered my question myself:
> >
> > merge parents $sha1 [$sha1...] original $sha1 $msg
>
> When you are reparenting, how would original commit get in the picture?
> You wouldn't want the resulting merge to claim it merged X (which would be
> what's in original's commit log) when in fact it now merged Y because the
> user reparented it, would you?
Oh yes, I would! Example:
A - B - C
/
X - Y
If I merged X into B by accident, but actually meant to merge Y, then C'
should still come after B', no?
Ciao,
Dscho
^ permalink raw reply
* Re: diff settings
From: Ted Pavlic @ 2009-01-25 21:02 UTC (permalink / raw)
To: Keith Cascio; +Cc: Teemu Likonen, git
In-Reply-To: <alpine.GSO.2.00.0901241159050.23073@kiwi.cs.ucla.edu>
>> git config --global alias.dff "diff -w"
>>
>> Then "git dff" is your new "git diff -w". :-)
>
> That feature is gonna come in handy. It doesn't 100% fulfill my needs here but
> I like it! Thanks, I did not know about alias.*
Mercurial has a "defaults.*" that does exactly what you want. That is,
you can say
[defaults]
diff = -w
and "hg diff" will automatically do "hg diff -w". Such a feature might
be a nice addition to git.
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: diff settings
From: Keith Cascio @ 2009-01-25 21:11 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Teemu Likonen, git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <497CD352.2060402@tedpavlic.com>
On Sun, 25 Jan 2009, Ted Pavlic wrote:
> Mercurial has a "defaults.*" that does exactly what you want. That is, you can
> say
>
> [defaults]
> diff = -w
>
> and "hg diff" will automatically do "hg diff -w". Such a feature might be a
> nice addition to git.
Thank you, that is very interesting. I just submitted a patch this morning that
does exactly what you describe, but I called it "primer" instead of "defaults"
because it seemed more explicit. Check it out.
-- Keith
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Felipe Contreras @ 2009-01-25 21:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Hannu Koivisto, git
In-Reply-To: <7vvds3dszy.fsf@gitster.siamese.dyndns.org>
On Sun, Jan 25, 2009 at 10:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> It's much easier for everyone to just use git config --global than
>> explain how create and edit the .gitconfig file. If this is explained
>> it shouldn't be in the "Telling git your name" section.
>
> I think it is Ok to have, and it probably is helpful to have, a document
> that accompanies the generic manual, "Platform supplement", to explain
> things like "On this platform, what is referred to as $HOME in the generic
> manual is implemented as %HOMEDRIVE%%HOMEPATH%", to cover peculiarities of
> each platform.
>
> But I think it is going backwards to butcher the description in the main
> manual in order to make the platform supplement shorter. Even Windows is
> not a good enough reason to break the logical ordering of how things
> should be best taught to the readers of the manual, which is not specific
> to a platform.
That's why I think there should be a whole section regarding git
configuration before "Telling git your name".
However, my last proposal was to have both the git config --global
*and* the $HOME/.gitconfig description. Is there any argument against
that?
--
Felipe Contreras
^ permalink raw reply
* [PATCH] Mention "local convention" rule in the CodingGuidelines
From: Nanako Shiraishi @ 2009-01-25 21:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The document suggests to imitate the existing code, but didn't
say which existing code it should imitate. This clarifies.
Signed-off-by: しらいしななこ <nanako3@lavabit.com>
---
Quoting Junio C Hamano <gitster@pobox.com>:
> It is always preferable to match the _local_ convention. I'd expect a new
> script added to git suite to match my preference (the one I showed you in
> my comments to you that is used in git-am, which is what you suggested
> above), but I'd expect a modification to mergetool to match the style
> mergetool already uses.
Documentation/CodingGuidelines | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index f628c1f..664c6c2 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -21,8 +21,13 @@ code. For git in general, three rough rules are:
As for more concrete guidelines, just imitate the existing code
(this is a good guideline, no matter which project you are
-contributing to). But if you must have a list of rules,
-here they are.
+contributing to). It is always preferable to match the _local_
+convention. A new code added to git suite is expected to match
+the overall style of existing code. A modification to an existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
For shell scripts specifically (not exhaustive):
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Jeff King @ 2009-01-25 21:44 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Johannes Schindelin, Hannu Koivisto, git
In-Reply-To: <94a0d4530901251312q4201d51btd806fe860a12afd6@mail.gmail.com>
On Sun, Jan 25, 2009 at 11:12:57PM +0200, Felipe Contreras wrote:
> However, my last proposal was to have both the git config --global
> *and* the $HOME/.gitconfig description. Is there any argument against
> that?
This is like the fifth time you have asked, and for some reason, nobody
seems to have said yes or no. So I will go ahead and say: yes, I think
that is a fine idea.
I think there should also be some explanatory text that indicates they
are totally interchangeable for the rest of the document. Something
like: "When we show configuration in the rest of this document, we will
use format X [I think probably "git config $VAR $VALUE"]. But you can
use whichever method you are most comfortable with."
-Peff
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Jakub Narebski @ 2009-01-25 22:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Sverre Rabbelier, git
In-Reply-To: <7vwscjceec.fsf@gitster.siamese.dyndns.org>
On Sun, 25 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > So maybe I answered my question myself:
> >
> > merge parents $sha1 [$sha1...] original $sha1 $msg
>
> When you are reparenting, how would original commit get in the picture?
> You wouldn't want the resulting merge to claim it merged X (which would be
> what's in original's commit log) when in fact it now merged Y because the
> user reparented it, would you?
Well, the subject part of merge (with merged branches names) shouldn't,
I guess, change. The summary (shortlog) part might, or perhaps even
should following rewrite (if it was present here).
But there is one issue I am wondering about: could we pick up _merge_
_resolution_? So if you have evil merge, and the change is for example
splitting commits without visible final changes, or just changing some
commit message before merge, it would get recreated without problems?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v1 0/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-25 22:07 UTC (permalink / raw)
To: Keith Cascio; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.GSO.2.00.0901251239000.12651@kiwi.cs.ucla.edu>
On Sun, Jan 25, 2009 at 12:41:21PM -0800, Keith Cascio wrote:
> > I am puzzled.
> >
> > The gitattributes mechanism is about per-path settings, but I do not
> > think a mnemonicprefix that is per-path makes much sense.
>
> That was just an example (perhaps poorly chosen). What I meant to
> suggest is making gitattributes consistent with gitconfig WRT at least
> the [diff] section. But maybe that's not appropriate. Thanks for the
> insight.
I don't think you want it entirely consistent. What would
diff.renamelimit mean in the context of a gitattribute? But I do think
it makes sense for some (like specific diff options such as whitespace
handling).
Also, if you're going to have options that apply to gitattributes diff
drivers _and_ as a general fallback, I think we need to define when the
fallback kicks in. That is, let's say I have a gitattributes file like
this:
*.c diff=c
and my config says:
[diff]
opt1 = val1_default
opt2 = val2_default
[diff "c"]
opt1 = val1_c
Now obviously if I want to use opt1 for my C files, it should be val1_c.
But if I want to use opt2, what should it use? There are two reasonable
choices, I think:
1. You use val2_default. The rationale is that the "c" diff driver did
not define an opt2, so you fall back to the global default.
2. It is unset. The rationale is that you are using the "c" diff
driver, and it has left the value unset. The default then means "if
you have no diff driver setup".
I suspect "1" is what people would want most of the time, but "2" is
actually more flexible (since there is otherwise no way to say "I
explicitly left diff.c.opt2 unset").
If (2) is desired, I think it makes more sense to put such "default"
options into their own diff driver section. Like:
[diff "default"]
opt2 = whatever
And then it is more clear that once you have selected the "c" diff
driver, the values in the other "default" are not relevant.
I don't think this is a huge issue overall, but it occurs to me that we
have just added diff.wordRegex and diff.*.wordRegex. So it makes sense
to think for a minute which behavior we want before it ships and we are
stuck with backwards compatibility forever.
-Peff
^ permalink raw reply
* Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-25 22:11 UTC (permalink / raw)
To: Keith Cascio; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <alpine.GSO.2.00.0901251033160.12651@kiwi.cs.ucla.edu>
On Sun, Jan 25, 2009 at 10:44:25AM -0800, Keith Cascio wrote:
> The name "primer" is open to discussion, of course. But I like it.
> From Merriam-Webster:
> primer n 1: a device for priming 2: material used in priming a surface
> prime vb 1: fill, load 2: to prepare for firing 3: to apply the first color, coating or preparation to <~ a wall>
FWIW, I found it very confusing. I would have expected "diff.options" or
"diff.defaults". There is also some precedent in the form of
GIT_DIFF_OPTS, but I believe it _only_ handles --unified and -u, so it
is not necessarily a useful model.
-Peff
^ permalink raw reply
* [PATCH] git-svn: add --ignore-paths option for fetching
From: Vitaly "_Vi" Shukela @ 2009-01-25 22:21 UTC (permalink / raw)
To: git; +Cc: Vitaly "_Vi" Shukela
This will be useful when somebody want to checkout something partially from
repository with some non-standart layout or exclude some files from it.
Example: repository has structure /module-{a,b,c}/{trunk,branches,tags}/...
Modules are interdependent, and you want it to be single repostory (to commit
to all modules simultaneously and view complete history), but do not want
branches and tags be checked out into working copy.
Other use case is excluding some large blobs.
The quirk for now is that user must specify this option every fetch/rebase;
in other case he may get extra files or "file not found" errors. It may be
will be resolved by adding regular expression to .git/config into
[svn-remote ...] to make it persistent.
Signed-off-by: Vitaly "_Vi" Shukela <public_vi@tut.by>
---
git-svn.perl | 43 +++++++++++++++++++++++++++----------------
1 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d4cb538..40b0e9e 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -70,7 +70,8 @@ my ($_stdin, $_help, $_edit,
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
- 'no-auth-cache' => \$Git::SVN::Prompt::_no_auth_cache );
+ 'no-auth-cache' => \$Git::SVN::Prompt::_no_auth_cache,
+ 'ignore-paths=s' => \$SVN::Git::Fetcher::ignore_regex );
my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
'authors-file|A=s' => \$_authors,
'repack:i' => \$Git::SVN::_repack,
@@ -3245,6 +3246,21 @@ use warnings;
use Carp qw/croak/;
use File::Temp qw/tempfile/;
use IO::File qw//;
+use vars qw/ $ignore_regex/;
+
+# returns true if a given path is inside a ".git" directory
+sub in_dot_git($) {
+ $_[0] =~ m{(?:^|/)\.git(?:/|$)};
+}
+
+# 0 -- don't ignore, 1 -- ignore
+sub is_path_ignored($) {
+ my ($path) = @_;
+ return 1 if in_dot_git($path);
+ return 0 unless defined($ignore_regex);
+ return 1 if $path =~ m!$ignore_regex!o;
+ return 0;
+}
# file baton members: path, mode_a, mode_b, pool, fh, blob, base
sub new {
@@ -3292,11 +3308,6 @@ sub _mark_empty_symlinks {
\%ret;
}
-# returns true if a given path is inside a ".git" directory
-sub in_dot_git {
- $_[0] =~ m{(?:^|/)\.git(?:/|$)};
-}
-
sub set_path_strip {
my ($self, $path) = @_;
$self->{path_strip} = qr/^\Q$path\E(\/|$)/ if length $path;
@@ -3322,7 +3333,7 @@ sub git_path {
sub delete_entry {
my ($self, $path, $rev, $pb) = @_;
- return undef if in_dot_git($path);
+ return undef if is_path_ignored($path);
my $gpath = $self->git_path($path);
return undef if ($gpath eq '');
@@ -3352,7 +3363,7 @@ sub open_file {
my ($self, $path, $pb, $rev) = @_;
my ($mode, $blob);
- goto out if in_dot_git($path);
+ goto out if is_path_ignored($path);
my $gpath = $self->git_path($path);
($mode, $blob) = (command('ls-tree', $self->{c}, '--', $gpath)
@@ -3372,7 +3383,7 @@ sub add_file {
my ($self, $path, $pb, $cp_path, $cp_rev) = @_;
my $mode;
- if (!in_dot_git($path)) {
+ if (!is_path_ignored($path)) {
my ($dir, $file) = ($path =~ m#^(.*?)/?([^/]+)$#);
delete $self->{empty}->{$dir};
$mode = '100644';
@@ -3383,7 +3394,7 @@ sub add_file {
sub add_directory {
my ($self, $path, $cp_path, $cp_rev) = @_;
- goto out if in_dot_git($path);
+ goto out if is_path_ignored($path);
my $gpath = $self->git_path($path);
if ($gpath eq '') {
my ($ls, $ctx) = command_output_pipe(qw/ls-tree
@@ -3407,7 +3418,7 @@ out:
sub change_dir_prop {
my ($self, $db, $prop, $value) = @_;
- return undef if in_dot_git($db->{path});
+ return undef if is_path_ignored($db->{path});
$self->{dir_prop}->{$db->{path}} ||= {};
$self->{dir_prop}->{$db->{path}}->{$prop} = $value;
undef;
@@ -3415,7 +3426,7 @@ sub change_dir_prop {
sub absent_directory {
my ($self, $path, $pb) = @_;
- return undef if in_dot_git($pb->{path});
+ return undef if is_path_ignored($path);
$self->{absent_dir}->{$pb->{path}} ||= [];
push @{$self->{absent_dir}->{$pb->{path}}}, $path;
undef;
@@ -3423,7 +3434,7 @@ sub absent_directory {
sub absent_file {
my ($self, $path, $pb) = @_;
- return undef if in_dot_git($pb->{path});
+ return undef if is_path_ignored($path);
$self->{absent_file}->{$pb->{path}} ||= [];
push @{$self->{absent_file}->{$pb->{path}}}, $path;
undef;
@@ -3431,7 +3442,7 @@ sub absent_file {
sub change_file_prop {
my ($self, $fb, $prop, $value) = @_;
- return undef if in_dot_git($fb->{path});
+ return undef if is_path_ignored($fb->{path});
if ($prop eq 'svn:executable') {
if ($fb->{mode_b} != 120000) {
$fb->{mode_b} = defined $value ? 100755 : 100644;
@@ -3447,7 +3458,7 @@ sub change_file_prop {
sub apply_textdelta {
my ($self, $fb, $exp) = @_;
- return undef if (in_dot_git($fb->{path}));
+ return undef if is_path_ignored($fb->{path});
my $fh = $::_repository->temp_acquire('svn_delta');
# $fh gets auto-closed() by SVN::TxDelta::apply(),
# (but $base does not,) so dup() it for reading in close_file
@@ -3494,7 +3505,7 @@ sub apply_textdelta {
sub close_file {
my ($self, $fb, $exp) = @_;
- return undef if (in_dot_git($fb->{path}));
+ return undef if is_path_ignored($fb->{path});
my $hash;
my $path = $self->git_path($fb->{path});
--
1.5.6.5
^ permalink raw reply related
* [PATCH] git-svn: Add test for --ignore-paths parameter
From: Vitaly "_Vi" Shukela @ 2009-01-25 22:21 UTC (permalink / raw)
To: git; +Cc: Vitaly "_Vi" Shukela
In-Reply-To: <1232922102-6144-2-git-send-email-public_vi@tut.by>
Added a test for this option, similar to (and based on) t9133 about ignorance of .git directories
Signed-off-by: Vitaly "_Vi" Shukela <public_vi@tut.by>
---
t/t9134-git-svn-ignore-paths.sh | 97 +++++++++++++++++++++++++++++++++++++++
1 files changed, 97 insertions(+), 0 deletions(-)
create mode 100755 t/t9134-git-svn-ignore-paths.sh
diff --git a/t/t9134-git-svn-ignore-paths.sh b/t/t9134-git-svn-ignore-paths.sh
new file mode 100755
index 0000000..094cb6a
--- /dev/null
+++ b/t/t9134-git-svn-ignore-paths.sh
@@ -0,0 +1,97 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Eric Wong
+#
+
+test_description='git svn property tests'
+. ./lib-git-svn.sh
+
+test_expect_success 'setup test repository' '
+ svn co "$svnrepo" s &&
+ (
+ cd s &&
+ mkdir qqq www &&
+ echo test_qqq > qqq/test_qqq.txt &&
+ echo test_www > www/test_www.txt &&
+ svn add qqq &&
+ svn add www &&
+ svn commit -m "create some files" &&
+ svn up &&
+ echo hi >> www/test_www.txt &&
+ svn commit -m "modify www/test_www.txt" &&
+ svn up
+ )
+'
+
+test_expect_success 'clone an SVN repository with ignored www directory' '
+ git svn clone --ignore-paths="^www" "$svnrepo" g &&
+ echo test_qqq > expect &&
+ for i in g/*/*.txt; do cat $i >> expect2; done &&
+ test_cmp expect expect2
+'
+
+test_expect_success 'SVN-side change outside of www' '
+ (
+ cd s &&
+ echo b >> qqq/test_qqq.txt &&
+ svn commit -m "SVN-side change outside of www" &&
+ svn up &&
+ svn log -v | fgrep "SVN-side change outside of www"
+ )
+'
+
+test_expect_success 'update git svn-cloned repo' '
+ (
+ cd g &&
+ git svn rebase --ignore-paths="^www" &&
+ echo -e "test_qqq\nb" > expect &&
+ for i in */*.txt; do cat $i >> expect2; done &&
+ test_cmp expect2 expect &&
+ rm expect expect2
+ )
+'
+
+test_expect_success 'SVN-side change inside of ignored www' '
+ (
+ cd s &&
+ echo zaq >> www/test_www.txt
+ svn commit -m "SVN-side change inside of www/test_www.txt" &&
+ svn up &&
+ svn log -v | fgrep "SVN-side change inside of www/test_www.txt"
+ )
+'
+
+test_expect_success 'update git svn-cloned repo' '
+ (
+ cd g &&
+ git svn rebase --ignore-paths="^www" &&
+ echo -e "test_qqq\nb" > expect &&
+ for i in */*.txt; do cat $i >> expect2; done &&
+ test_cmp expect2 expect &&
+ rm expect expect2
+ )
+'
+
+test_expect_success 'SVN-side change in and out of ignored www' '
+ (
+ cd s &&
+ echo cvf >> www/test_www.txt
+ echo ygg >> qqq/test_qqq.txt
+ svn commit -m "SVN-side change in and out of ignored www" &&
+ svn up &&
+ svn log -v | fgrep "SVN-side change in and out of ignored www"
+ )
+'
+
+test_expect_success 'update git svn-cloned repo again' '
+ (
+ cd g &&
+ git svn rebase --ignore-paths="^www" &&
+ echo -e "test_qqq\nb\nygg" > expect &&
+ for i in */*.txt; do cat $i >> expect2; done &&
+ test_cmp expect2 expect &&
+ rm expect expect2
+ )
+'
+
+test_done
--
1.5.6.5
^ permalink raw reply related
* [PATCH] git-svn: documented --ignore-paths
From: Vitaly "_Vi" Shukela @ 2009-01-25 22:21 UTC (permalink / raw)
To: git; +Cc: Vitaly "_Vi" Shukela
In-Reply-To: <1232922102-6144-1-git-send-email-public_vi@tut.by>
Documented --ignore-paths option of git-svn to inform users about
the feature and provide some examples.
Signed-off-by: Vitaly "_Vi" Shukela <public_vi@tut.by>
---
Documentation/git-svn.txt | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 63d2f5e..2215fcb 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -103,6 +103,19 @@ repository to be able to interoperate with someone else's local Git
repository, either don't use this option or you should both use it in
the same local timezone.
+--ignore-paths=<regex>;;
+ This allows one to specify Perl regular expression that will
+ cause skipping of all matching paths from checkout from SVN.
+ Examples:
+
+ --ignore-paths="^doc" - skip "doc*" directory for every fetch.
+
+ --ignore-paths="^[^/]+/(?:branches|tags)" - skip "branches"
+ and "tags" of first level directories.
+
+ Regular expression is not persistent, you should specify
+ it every time when fetching.
+
'clone'::
Runs 'init' and 'fetch'. It will automatically create a
directory based on the basename of the URL passed to it;
--
1.5.6.5
^ permalink raw reply related
* [PATCH] gitweb: last-modified time should be commiter, not author
From: Giuseppe Bilotta @ 2009-01-25 22:42 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Giuseppe Bilotta
In-Reply-To: <1232686121-1800-5-git-send-email-giuseppe.bilotta@gmail.com>
The last-modified time header added by RSS to increase cache hits from
readers should be set to the date the repository was last modified. The
author time in this respect is not a good guess because the last commit
might come from a oldish patch.
Use the committer time for the last-modified header to ensure a more
correct guess of the last time the repository was modified.
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 756868a..8c49c75 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6015,7 +6015,7 @@ sub git_feed {
}
if (defined($commitlist[0])) {
%latest_commit = %{$commitlist[0]};
- %latest_date = parse_date($latest_commit{'author_epoch'});
+ %latest_date = parse_date($latest_commit{'committer_epoch'});
print $cgi->header(
-type => $content_type,
-charset => 'utf-8',
--
1.5.6.5
^ permalink raw reply related
* [PATCH] gitweb: check if-modified-since for feeds
From: Giuseppe Bilotta @ 2009-01-25 22:42 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Giuseppe Bilotta
In-Reply-To: <1232923370-4427-1-git-send-email-giuseppe.bilotta@gmail.com>
Offering Last-modified header for feeds is only half the work: we should
also check that same date against If-modified-since, and bail out early
with 304 Not Modified.
---
gitweb/gitweb.perl | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8c49c75..0a5d229 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6015,7 +6015,25 @@ sub git_feed {
}
if (defined($commitlist[0])) {
%latest_commit = %{$commitlist[0]};
- %latest_date = parse_date($latest_commit{'committer_epoch'});
+ my $latest_epoch = $latest_commit{'committer_epoch'};
+ %latest_date = parse_date($latest_epoch);
+ my $if_modified = $cgi->http('IF_MODIFIED_SINCE');
+ if (defined $if_modified) {
+ my $since;
+ if (eval { require HTTP::Date; 1; }) {
+ $since = HTTP::Date::str2time($if_modified);
+ } elsif (eval { require Time::ParseDate; 1; }) {
+ $since = Time::ParseDate::parsedate($if_modified, GMT => 1);
+ }
+ if (defined $since && $latest_epoch <= $since) {
+ print $cgi->header(
+ -type => $content_type,
+ -charset => 'utf-8',
+ -last_modified => $latest_date{'rfc2822'},
+ -status => 304);
+ return;
+ }
+ }
print $cgi->header(
-type => $content_type,
-charset => 'utf-8',
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] git-svn: add --ignore-paths option for fetching
From: Eric Wong @ 2009-01-25 22:42 UTC (permalink / raw)
To: Thomas Rast; +Cc: Vitaly _Vi Shukela, git
In-Reply-To: <200901251521.15591.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> wrote:
> Vitaly "_Vi" Shukela wrote:
> >
> > Signed-off-by: Vitaly "_Vi" Shukela <public_vi@tut.by>
>
> This would be a good place to explain why this is useful, and (if
> applicable) why you chose to implement it the way you did.
>
> > --- a/Documentation/git-svn.txt
> > +++ b/Documentation/git-svn.txt
> > @@ -96,6 +96,10 @@ COMMANDS
> > 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.
> > +--ignore-paths=<regex>;;
> > + This allows one to specify regular expression that will
> > + cause skipping of all matching paths from checkout from SVN.
> > + Example: --ignore-paths='^doc'
> >
> > This doesn't interfere with interoperating with the Subversion
> > repository you cloned from, but if you wish for your local Git
>
> You put the --ignore-paths explanation in the middle of the
> --localtime documentation (the last paragraph quoted still talks about
> --localtime).
>
> > @@ -3245,6 +3246,15 @@ use warnings;
> > use Carp qw/croak/;
> > use File::Temp qw/tempfile/;
> > use IO::File qw//;
> > +use vars qw/ $ignoreRegex/;
> > +
> > +# 0 -- don't ignore, 1 -- ignore
> > +sub isPathIgnored($) {
> > + return 0 unless defined($ignoreRegex);
> > + my $path = shift;
> > + return 1 if $path =~ m!^$ignoreRegex!o;
> > + return 0;
> > +}
>
> This is the first function in git-svn.perl using camelCase. Consider
> sticking to the current style and spelling it is_path_ignored().
Also, indentation is always done with tabs in git-svn (and the vast
majority of git as well).
> > @@ -3372,11 +3384,14 @@ sub add_file {
> > my ($self, $path, $pb, $cp_path, $cp_rev) = @_;
> > my $mode;
> >
> > + goto out if isPathIgnored($path);
> > +
> > if (!in_dot_git($path)) {
> > my ($dir, $file) = ($path =~ m#^(.*?)/?([^/]+)$#);
> > delete $self->{empty}->{$dir};
> > $mode = '100644';
> > }
> > +out:
> > { path => $path, mode_a => $mode, mode_b => $mode,
> > pool => SVN::Pool->new, action => 'A' };
> > }
>
> You broke the symmetry here, while all other hunks just add an
> equivalent check to the existing in_dot_git().
>
> However, the latter makes me wonder if it would be cleaner to move the
> in_dot_git() test to isPathIgnored (er, is_path_ignored) too?
Thanks for the review, Thomas. I agree with all your suggestions.
Vitaly: thank you for the patch. Can you also provide a testcase to
ensure this functionality doesn't break during refactorings? Thanks.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: add --ignore-paths option for fetching
From: public_vi @ 2009-01-25 22:48 UTC (permalink / raw)
To: Eric Wong; +Cc: Thomas Rast, git
In-Reply-To: <20090125224238.GA31581@untitled>
Eric Wong wrote:
> Thomas Rast <trast@student.ethz.ch> wrote:
>
>
> Also, indentation is always done with tabs in git-svn (and the vast
> majority of git as well).
>
>
Whitespace is invisible for me now, I only checked according to
Documentation/SubmittingPatches about extra lines adds or removes caused
just by whitespace difference.
>
>
> Vitaly: thank you for the patch. Can you also provide a testcase to
> ensure this functionality doesn't break during refactorings? Thanks.
>
>
Already done it with testcase. There are two new packs of patches sent
to git@vger.kernel.org, the first is outdated too, the second is current.
(I don't yet completely know how things should be done).
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Wincent Colaiuta @ 2009-01-25 22:55 UTC (permalink / raw)
To: Jeff King
Cc: Felipe Contreras, Junio C Hamano, Johannes Schindelin,
Hannu Koivisto, git
In-Reply-To: <20090125214435.GA20173@coredump.intra.peff.net>
El 25/1/2009, a las 22:44, Jeff King escribió:
> On Sun, Jan 25, 2009 at 11:12:57PM +0200, Felipe Contreras wrote:
>
>> However, my last proposal was to have both the git config --global
>> *and* the $HOME/.gitconfig description. Is there any argument against
>> that?
>
> This is like the fifth time you have asked, and for some reason,
> nobody
> seems to have said yes or no. So I will go ahead and say: yes, I think
> that is a fine idea.
>
> I think there should also be some explanatory text that indicates they
> are totally interchangeable for the rest of the document. Something
> like: "When we show configuration in the rest of this document, we
> will
> use format X [I think probably "git config $VAR $VALUE"]. But you can
> use whichever method you are most comfortable with."
I already suggested something similar about 4 days ago:
http://article.gmane.org/gmane.comp.version-control.git/106673/
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Keith Cascio @ 2009-01-25 22:58 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090125221141.GA17490@coredump.intra.peff.net>
On Sun, 25 Jan 2009, Jeff King wrote:
> FWIW, I found it very confusing. I would have expected "diff.options" or
> "diff.defaults". There is also some precedent in the form of GIT_DIFF_OPTS,
> but I believe it _only_ handles --unified and -u, so it is not necessarily a
> useful model.
OK, point taken. I wasn't trying to be idiosyncratic at all. Just trying to be
explicit and avoid all confusion. Since all diff options already have default
values, primer looks to me like the layer one step above defaults, hence the
painting analogy. Mercurial calls it "defaults", but that doesn't mean we
should necessarily follow in their footsteps (see
http://article.gmane.org/gmane.comp.version-control.git/107103).
I think being as clear as possible about what primer is, that is it NOT
defaults, helps to feel more comfortable with its consequences, i.e. in my
opinion, that it will not break things.
-- Keith
^ permalink raw reply
* Re: [PATCH 0/2] Add submodule-support to git archive
From: Lars Hjemli @ 2009-01-25 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <7veiyrdszf.fsf@gitster.siamese.dyndns.org>
On Sun, Jan 25, 2009 at 21:35, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>> On Sun, Jan 25, 2009 at 05:53, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>>> What would I do to try this new series? Fork a branch from Junio's master branch,
>>> apply your new patches, and merge the result to Junio's next?
>>
>> Yes, that sounds right (btw: the series is buildt on top of 5dc1308562
>> (Merge branch 'js/patience-diff') and can be pulled from
>> git://hjemli.net/pub/git/git lh/traverse-gitlinks).
>>
>> But before merging with 'next', you'll need to `git revert -m 1 bdf31cbc00`.
>
> Yuck, that is too much to ask for regular testers and users.
Sorry about that.
> Could we switch to incremental refinements once a series hits next, pretty
> please?
The problem in this particular case is that the design has changed so
much since the first iteration that we're not really talking about
incremental refinements but rather a different approach to the same
problem.
If you want me to build on top of the series in next anyways, would it
be acceptable if the first patch on top of ee306d2d59 reverts the
previous attempt? I think the rest of the series will be easier to
review that way.
--
larsh
^ permalink raw reply
* [PATCH 0/3] Valgrind support
From: Johannes Schindelin @ 2009-01-25 23:18 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901212332030.3586@pacific.mpi-cbg.de>
I finally decided to give in on both the lock (let's see how many races
we encounter in reality...) and the searching the PATH and handling .sh
and .perl scripts, too. The latter issue is handled by 3/3, which is up
for discussion.
Oh, and BTW, this is vs 'next', and according to my tests, valgrind finds
at least one issue.
Jeff King (1):
valgrind: ignore ldso and more libz errors
Johannes Schindelin (2):
Add valgrind support in test scripts
Valgrind support: check for more than just programming errors
t/README | 8 +++++-
t/test-lib.sh | 66 +++++++++++++++++++++++++++++++++++++++++++++-
t/valgrind/.gitignore | 1 +
t/valgrind/default.supp | 45 ++++++++++++++++++++++++++++++++
t/valgrind/valgrind.sh | 12 ++++++++
5 files changed, 129 insertions(+), 3 deletions(-)
create mode 100644 t/valgrind/.gitignore
create mode 100644 t/valgrind/default.supp
create mode 100755 t/valgrind/valgrind.sh
^ 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