* Re: git log -p file.c
From: Jakub Narebski @ 2007-06-14 21:55 UTC (permalink / raw)
To: git
In-Reply-To: <20070614090217.GA8271@informatik.uni-freiburg.de>
[Cc: git@vger.kernel.org]
Uwe Kleine-Koenig wrote:
> when I run
>
> git log -p file.c
>
> I don't get the complete change a commit introduces but only how file.c
> changed. This is kind of surprising for me, I had expected to get the
> whole diff.
Try unfortunately _undocumented_ --full-diff option to git-log.
git log -p --full-diff -- file.c
(the --full-diff option was introduced in commit-477f2b41 without adding
appropriate info to Documentation/git-log.txt)
> And is it intended that (clean) merges are shown?
Path limiting simplifies history, and might linearize it (i.e. merges
become non-merges).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git log -p file.c
From: Linus Torvalds @ 2007-06-14 23:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f4shn6$r6q$1@sea.gmane.org>
[ Nit-picking. Not really important. But I reacted to a part of Jakub's
explanation ]
On Thu, 14 Jun 2007, Jakub Narebski wrote:
>
> > And is it intended that (clean) merges are shown?
>
> Path limiting simplifies history, and might linearize it (i.e. merges
> become non-merges).
Actually, path limiting, when it simplifies merges, will *only* simplify a
merge when one of the parents was identical to the end result (which
implies that the other parents were obviously not interesting as far as
the end result is concerned!).
But that has a secondary effect: such a merge will then (by definition)
always be simplified away, since the simplified merge no longer makes any
changes to the set of files in question!
So "merges become non-merges" is not really true (except in a very
internal sense that will be invisible to the outside). They either stay as
merges (end result is different from any of the parents on their own), or
they go away entirely (end result is identical to one of the parents and
the merge ends up not containing any change atr all).
This explanation may, of course, be more nit-picking than anybody really
wanted to hear.
Linus
^ permalink raw reply
* Re: [RFD] Documentation/HOWTO translated into Japanese
From: Kyle Moffett @ 2007-06-15 0:29 UTC (permalink / raw)
To: Tony Luck
Cc: Matt Mackall, Greg KH, Matthias Schniedermeyer, Jesper Juhl,
Tsugikazu Shibata, LKML Kernel, m-ikeda, git
In-Reply-To: <12c511ca0706111038j37e188b6n2677b1789d14de23@mail.gmail.com>
On Jun 11, 2007, at 13:38:10, Tony Luck wrote:
>> I'd rather have a single file, marked "Japanese" (in Japanese),
>> that had pointers to current translations. These will always be at
>> least as current as whatever we have in the tree, if not more so.
>> Especially when someone is trying to figure out how to work based
>> on the year-old kernel their embedded vendor gave them.
>
> Knowing whether a translation is current or not would be useful ...
> perhaps the translated files could include the GIT blob SHA1 of the
> version they were translated from (and some human readable version
> string too :-) This would allow someone reading the documentation
> to know whether is really was current. If it isn't, it provides an
> easy path to see what changed in the source document since the
> translation was made. This same diff should lighten the load for
> people maintaining the translation.
Well, actually, if you're going that route then extend GIT to have
support for "related" files. Essentially you should be able to add
metadata to a git tree which says: "files $SHA1-$PATH1, $SHA2-$PATH2,
[...], are related". Then there would be a "git list-related"
command with a "--mismatch" option which would list paths for which
$SHA1 doesn't correspond to $PATH1 or $SHA2 doesn't correspond to
$PATH2, etc. Some clever updating of related-status during commit/
clone/pull/etc could store information in the index about whether or
not any given file is up-to-date with respect to its co-related files.
For translations, when the English version of a document is updated
it will automatically result in a "mismatch", allowing translators to
do a simple git-diff and see what happened. Likewise, if the
Japanese document is updated without changing the relationship then
it might mean that somebody should see what changed and update the
English version as well. If you determine that the change was
irrelevant for the other language (spelling/grammar fixes, etc), then
you just update the relationship and commit that change.
It would probably be pretty trivial to implement a prototype using a
'.gitrelated' file in the root of the git tree, although better
integration with the index would really speed handling with lots of
related files; instead of linear searching just iterate over the
prepared-during-checkout "out-of-date" list.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: pull into dirty working tree
From: Martin Langhoff @ 2007-06-15 0:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Bill Lear, git
In-Reply-To: <alpine.LFD.0.98.0706140836450.14121@woody.linux-foundation.org>
On 6/15/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Well, the thing is, I actually pull into dirty trees all the time. So I
> can really see the point of wanting to have some dirty state (you're not
> ready to commit it yet), but still wanting to update your tree to some
> newer state..
Right now git merges/fforwards well with dirty state as long as the
same path is not touched on both sides. But there are several
situations where it could do better allowing those ops to go through
if they don't result in any conflict.
- For Fast Forwards on a dirty path - attempt the merge on a temp file
and refuse to complete the FF there is a conflict.
- For merges on a dirty path, attempt the merge. If both the tree
merge _and_ the subsequent with the dirty state are clean, then there
is no problem updating the checkout.
In both cases, we can still go ahead in the case of a conflict against
the local state and give the user the normal conflict markers (or
separate files of the patch doesn't apply at all. The situation where
I think it is valid to refuse to go ahead is in the "merge on dirty
path" where the tree merge results in a conflict. Too many states to
keep track of -- not for git but for the user.
cheers,
martin
^ permalink raw reply
* [PATCH] cvsserver: Actually implement --export-all
From: Frank Lichtenheld @ 2007-06-15 1:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Martin Langhoff, Frank Lichtenheld
In-Reply-To: <11818693133210-git-send-email-frank@lichtenheld.de>
Embarrassing bug number two in my options patch.
Also enforce that --export-all is only ever used together with an
explicit whitelist. Otherwise people might export every git repository
on the whole system without realising.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
Documentation/git-cvsserver.txt | 3 ++-
git-cvsserver.perl | 8 +++++++-
t/t9400-git-cvsserver-server.sh | 16 ++++++++++++++++
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 6d1e311..60d0bcf 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -38,7 +38,8 @@ Prepend 'path' to requested CVSROOT
Don't allow recursing into subdirectories
--export-all::
-Don't check for `gitcvs.enabled` in config
+Don't check for `gitcvs.enabled` in config. You also have to specify a list
+of allowed directories (see below) if you want to use this option.
--version, -V::
Print version information and exit
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index f78afe8..5cbf27e 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -130,6 +130,11 @@ if (@ARGV) {
# everything else is a directory
$state->{allowed_roots} = [ @ARGV ];
+# don't export the whole system unless the users requests it
+if ($state->{'export-all'} && !@{$state->{allowed_roots}}) {
+ die "--export-all can only be used together with an explicit whitelist\n";
+}
+
# if we are called with a pserver argument,
# deal with the authentication cat before entering the
# main loop
@@ -276,7 +281,8 @@ sub req_Root
my $enabled = ($cfg->{gitcvs}{$state->{method}}{enabled}
|| $cfg->{gitcvs}{enabled});
- unless ($enabled && $enabled =~ /^\s*(1|true|yes)\s*$/i) {
+ unless ($state->{'export-all'} ||
+ ($enabled && $enabled =~ /^\s*(1|true|yes)\s*$/i)) {
print "E GITCVS emulation needs to be enabled on this repo\n";
print "E the repo config file needs a [gitcvs] section added, and the parameter 'enabled' set to 1\n";
print "E \n";
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 9b69452..b442b5d 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -173,6 +173,22 @@ test_expect_success 'req_Root (base-path)' \
test_expect_failure 'req_Root failure (base-path)' \
'cat request-anonymous | git-cvsserver --strict-paths --base-path $WORKDIR pserver $SERVERDIR >log 2>&1'
+GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false || exit 1
+
+test_expect_success 'req_Root (export-all)' \
+ 'cat request-anonymous | git-cvsserver --export-all pserver $WORKDIR >log 2>&1 &&
+ tail -n1 log | grep -q "^I LOVE YOU$"'
+
+test_expect_failure 'req_Root failure (export-all w/o whitelist)' \
+ 'cat request-anonymous | git-cvsserver --export-all pserver >log 2>&1
+ || false'
+
+test_expect_success 'req_Root (everything together)' \
+ 'cat request-base | git-cvsserver --export-all --strict-paths --base-path $WORKDIR/ pserver $SERVERDIR >log 2>&1 &&
+ tail -n1 log | grep -q "^I LOVE YOU$"'
+
+GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true || exit 1
+
#--------------
# CONFIG TESTS
#--------------
--
1.5.2.1
^ permalink raw reply related
* [PATCH] cvsserver: Let --base-path and pserver get along just fine
From: Frank Lichtenheld @ 2007-06-15 1:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Martin Langhoff, Frank Lichtenheld
Embarassing bug number one in my options patch.
Since the code for --base-path support rewrote
the cvsroot value after comparing it with a possible
existing value (i.e. from pserver authentication)
the check always failed.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
git-cvsserver.perl | 10 ++++++----
t/t9400-git-cvsserver-server.sh | 1 +
2 files changed, 7 insertions(+), 4 deletions(-)
I can also squash these two fix-ups into the previous commit
if preferred.
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 9fbd9db..f78afe8 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -212,15 +212,17 @@ sub req_Root
return 0;
}
+ my $cvsroot = $state->{'base-path'} || '';
+ $cvsroot =~ s#/+$##;
+ $cvsroot .= $data;
+
if ($state->{CVSROOT}
- && ($state->{CVSROOT} ne $data)) {
+ && ($state->{CVSROOT} ne $cvsroot)) {
print "error 1 Conflicting roots specified\n";
return 0;
}
- $state->{CVSROOT} = $state->{'base-path'} || '';
- $state->{CVSROOT} =~ s#/+$##;
- $state->{CVSROOT} .= $data;
+ $state->{CVSROOT} = $cvsroot;
$ENV{GIT_DIR} = $state->{CVSROOT} . "/";
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 392f890..9b69452 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -163,6 +163,7 @@ BEGIN AUTH REQUEST
anonymous
END AUTH REQUEST
+Root /gitcvs.git
EOF
test_expect_success 'req_Root (base-path)' \
--
1.5.2.1
^ permalink raw reply related
* Re: pull into dirty working tree
From: Linus Torvalds @ 2007-06-15 1:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Bill Lear, git
In-Reply-To: <46a038f90706141746n1cb69258r23ba676bbcf7c425@mail.gmail.com>
On Fri, 15 Jun 2007, Martin Langhoff wrote:
>
> Right now git merges/fforwards well with dirty state as long as the
> same path is not touched on both sides. But there are several
> situations where it could do better allowing those ops to go through
> if they don't result in any conflict.
>
> - For Fast Forwards on a dirty path - attempt the merge on a temp file
> and refuse to complete the FF there is a conflict.
> - For merges on a dirty path, attempt the merge. If both the tree
> merge _and_ the subsequent with the dirty state are clean, then there
> is no problem updating the checkout.
>
> In both cases, we can still go ahead in the case of a conflict against
> the local state and give the user the normal conflict markers (or
> separate files of the patch doesn't apply at all. The situation where
> I think it is valid to refuse to go ahead is in the "merge on dirty
> path" where the tree merge results in a conflict. Too many states to
> keep track of -- not for git but for the user.
I agree, but there is actually a practical implementation problem with
doing that:
- currently, we can decide *ahead* of time (by just looking at the index,
whether the index entry is clean, and the two branches) whether the
merge can go ahead or not.
- so we actually do two passes: the first pass checks that we can do what
we want to do cleanly, and the second pass actually starts changing the
working tree!
Now, if you actually start doing the *merge* thing, the biggest practical
problem ends up being that the natural place where you find out that
"oops, we can't get a clean result" is in phase 2 - *after* you have
potentially already done earlier merges in the working directory!
And that's unacceptable. A "git pull" needs to either fail early without
making any modifications at all (telling people that the tree is dirty and
cannot be merged), or it needs to complete but leave conflict markers.
But yeah, if you can check in stage 1 (_without_ changing the working
tree) whether the merge will work, then everything is fine.
Linus
^ permalink raw reply
* Re: StGIT vs. guilt: What's the difference?
From: Karl Hasselström @ 2007-06-15 3:05 UTC (permalink / raw)
To: Steven Grimm; +Cc: 'git'
In-Reply-To: <4671B96A.1080202@midwinter.com>
On 2007-06-14 14:55:54 -0700, Steven Grimm wrote:
> I've asked this on IRC a couple times and nobody seemed to have a
> good answer, so: These two tools seem like they are solving the same
> general problem using similar approaches. They are both under active
> development. In what areas is each of them stronger than the other?
> Why would one choose to use one of them instead of the other?
I have never had a close look at guilt, but from what I remember it
stores patches as plain old plaintext patches (corrections to this
statement welcome). StGIT uses git's object database.
I doubt there's anything that one model can handle that the other
cannot; the question is whether the two _implementations_ are feature
equivalent or not. And I can't answer that, since I know too little
about guilt.
I'm guessing guilt's creator might be a bit more qualified to answer;
from what I recall, he looked at StGIT, but decided to build his own
tool because StGIT did not meet his requirements.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-p4import.py robustness changes
From: Shawn O. Pearce @ 2007-06-15 3:13 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Junio C Hamano, git
In-Reply-To: <200706142344.29089.simon@lst.de>
Simon Hausmann <simon@lst.de> wrote:
> On Thursday 14 June 2007 07:35:38 Shawn O. Pearce wrote:
> > I do appreciate you taking the time to use filter-branch to try to
> > cleanup this history a bit. I really had originally planned on
> > pulling your tree through to my fastimport tree and then talking
> > Junio into merging with me. But after reading through this history I
> > don't want do that, because of the oneline summaries I just pointed
> > out above, and because of the missing SBO.
...
> I have started cleaning up the history even more by reworking the log messages
> of my commits (git-p4-enhanced-logs branch in fast-export, starting at the
> last page). Once that is done (I expect that to take a few days) I'll add the
> missing SOB lines with git-filter-branch and see if I can get an agreement
> from Han-Wen and Marius for doing the same with their commits (adding the
> missing lines).
OK.
> Would you be willing to reevaluate the situation regarding a merge once that's
> done?
Absolutely. I would like to see the git-p4 work in the main tree,
so it is more readily available to users, even though I'm not a p4
user myself. ;-)
--
Shawn.
^ permalink raw reply
* Re: [CORRECTED PATCH] Introduce file with the common default build-time items.
From: Shawn O. Pearce @ 2007-06-15 3:22 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20070614190739.GA3779@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> wrote:
> Thu, Jun 14, 2007 at 11:09:29AM -0400, Shawn O. Pearce wrote:
> > Eygene Ryabinkin <rea-git@codelabs.ru> wrote:
> > No, because Junio has already stated a desire to remove git-gui.git
> > from git.git and convert it to a proper subproject by the time of
> > Git 1.6. That means the git-gui/ subdirectory will become optional,
> > though I imagine most git-gui users will still have it. But not
> > all Git users are git-gui users. ;-)
>
> OK, it means that git-gui will be totally separated from the
> git.git? And one will download it as the separate tarball?
That's one option. But Junio and I are also considering keeping
it inside the git tarball as well, as many users have gotten used
to it being in the core Git distribution. I think it all depends
on if myself (or someone else) adds subproject recursion support
into git-archive. ;-)
No subproject recusion in git-archive will probably mean git-gui
would get dropped from the core git tarball. Given we're talking
about 1.6 timeframe I think we might be able to get that feature
working by then.
> > The best we can do is let the user pick their TCL_PATH and
> > TCLTK_PATH up in git's own Makefile, and have it pass down into
> > git-gui's Makefile when git-gui is being built from within git.
> > That is the arrangement we currently have.
>
> OK, fine, thanks for the explanations. The corrected patch follows.
...
> Makefile | 17 +++++++++++------
> common-make-vars.def | 11 +++++++++++
> configure.ac | 4 +++-
> 3 files changed, 25 insertions(+), 7 deletions(-)
> create mode 100644 common-make-vars.def
...
I dunno. 25 insertions and 7 deletions to reduce two uses of 'wish'
into one use of 'wish'? That hardly seems worth the additional
18 lines of code. Feels like code churn to me. And I rarely feel
code churn. I'm usually a lot more caviler about changing things
than Junio, Dscho, Nico, Linus, ...
--
Shawn.
^ permalink raw reply
* Re: pull into dirty working tree
From: Martin Langhoff @ 2007-06-15 3:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Bill Lear, git
In-Reply-To: <alpine.LFD.0.98.0706141801030.14121@woody.linux-foundation.org>
On 6/15/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> But yeah, if you can check in stage 1 (_without_ changing the working
> tree) whether the merge will work, then everything is fine.
Aha- so at phase 1 we know
- what paths are dirty in the checkout
- what paths of the merge need an actuall diff3 merge
perhaps we can do those diff3 merges elsewhere (tempfiles). If they
are trivial diff3 merges, then we can complete the merge operation
without touching the checkout. After this is complete, we can then
update the checkout...
cheers,
m
^ permalink raw reply
* [PATCH] Documentation/gitmodules: fix asciidoc
From: Sam Vilain @ 2007-06-15 3:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
---
I was getting documentation build errors without this
Documentation/gitmodules.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 7814b6a..5c9fe9c 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -5,9 +5,11 @@ NAME
----
gitmodules - defining submodule properties
+
SYNOPSIS
--------
-.gitmodules
+[verse]
+'.gitmodules'
DESCRIPTION
--
1.5.2.0.45.gfea6d-dirty
^ permalink raw reply related
* [PATCH] git-svn: avoid string eval for defining functions
From: Sam Vilain @ 2007-06-15 3:43 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
You don't need to use string eval to define new functions; assigning a
code reference to the target symbol table is enough.
---
git-svn.perl | 64 +++++++++++++++++++++++++++++----------------------------
1 files changed, 33 insertions(+), 31 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 4d35895..4ba0813 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -38,14 +38,16 @@ use IPC::Open3;
use Git;
BEGIN {
- my $s;
+ # import functions from Git into our packages, en masse
+ no strict 'refs';
foreach (qw/command command_oneline command_noisy command_output_pipe
command_input_pipe command_close_pipe/) {
- $s .= "*SVN::Git::Editor::$_ = *SVN::Git::Fetcher::$_ = ".
- "*Git::SVN::Migration::$_ = ".
- "*Git::SVN::Log::$_ = *Git::SVN::$_ = *$_ = *Git::$_; ";
+ for my $package ( qw(SVN::Git::Editor SVN::Git::Fetcher
+ Git::SVN::Migration Git::SVN::Log Git::SVN),
+ __PACKAGE__) {
+ *{"${package}::$_"} = \&{"Git::$_"};
+ }
}
- eval $s;
}
my ($SVN);
@@ -898,26 +900,26 @@ BEGIN {
# some options are read globally, but can be overridden locally
# per [svn-remote "..."] section. Command-line options will *NOT*
# override options set in an [svn-remote "..."] section
- my $e;
- foreach (qw/follow_parent no_metadata use_svm_props
- use_svnsync_props/) {
- my $key = $_;
+ no strict 'refs';
+ for my $option (qw/follow_parent no_metadata use_svm_props
+ use_svnsync_props/) {
+ my $key = $option;
$key =~ tr/_//d;
- $e .= "sub $_ {
- my (\$self) = \@_;
- return \$self->{-$_} if exists \$self->{-$_};
- my \$k = \"svn-remote.\$self->{repo_id}\.$key\";
- eval { command_oneline(qw/config --get/, \$k) };
- if (\$@) {
- \$self->{-$_} = \$Git::SVN::_$_;
+ my $prop = "-$option";
+ *$option = sub {
+ my ($self) = @_;
+ return $self->{$prop} if exists $self->{$prop};
+ my $k = "svn-remote.$self->{repo_id}.$key";
+ eval { command_oneline(qw/config --get/, $k) };
+ if ($@) {
+ $self->{$prop} = ${"Git::SVN::_$option"};
} else {
- my \$v = command_oneline(qw/config --bool/,\$k);
- \$self->{-$_} = \$v eq 'false' ? 0 : 1;
+ my $v = command_oneline(qw/config --bool/,$k);
+ $self->{$prop} = $v eq 'false' ? 0 : 1;
}
- return \$self->{-$_} }\n";
+ return $self->{$prop};
+ }
}
- $e .= "1;\n";
- eval $e or die $@;
}
my %LOCKFILES;
@@ -2956,17 +2958,17 @@ my ($can_do_switch, %ignored_err, $RA);
BEGIN {
# enforce temporary pool usage for some simple functions
- my $e;
- foreach (qw/rev_proplist get_latest_revnum get_uuid get_repos_root/) {
- $e .= "sub $_ {
- my \$self = shift;
- my \$pool = SVN::Pool->new;
- my \@ret = \$self->SUPER::$_(\@_,\$pool);
- \$pool->clear;
- wantarray ? \@ret : \$ret[0]; }\n";
+ no strict 'refs';
+ for my $f (qw/rev_proplist get_latest_revnum get_uuid get_repos_root/) {
+ my $SUPER = "SUPER::$f";
+ *$f = sub {
+ my $self = shift;
+ my $pool = SVN::Pool->new;
+ my @ret = $self->$SUPER(@_,$pool);
+ $pool->clear;
+ wantarray ? @ret : $ret[0];
+ };
}
-
- eval "$e; 1;" or die $@;
}
sub new {
--
1.5.2.0.45.gfea6d-dirty
^ permalink raw reply related
* Re: [PATCH] Documentation/gitmodules: fix asciidoc
From: Shawn O. Pearce @ 2007-06-15 3:49 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <11818789512948-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> ---
> I was getting documentation build errors without this
Yea, I got doc build errors today too from `next` but did not have
time to track down what was causing them. Something about the XML
not matching the DocBook DTD.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Documentation/gitmodules: fix asciidoc
From: Sam Vilain @ 2007-06-15 3:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070615034915.GE18491@spearce.org>
Shawn O. Pearce wrote:
> Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
>
>> ---
>> I was getting documentation build errors without this
>>
>
> Yea, I got doc build errors today too from `next` but did not have
> time to track down what was causing them. Something about the XML
> not matching the DocBook DTD.
Yep, the synopsis section did not have enough in it to satisfy the
requirements of asciidoc, so it generated an empty <refsynopsisinfo>
section which doesn't match the DocBook 4.2 DTD.
Perhaps there is another solution by fixing the asciidoc.conf... but
looks like voodoo to me :)
Sam.
^ permalink raw reply
* git-send-pack SIGSEGV..
From: Linus Torvalds @ 2007-06-15 4:29 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Daniel Barkalow
I haevn't had time to debug this at all, but
git push --tags all
actually SIGSEGV's for me on the git repository. "all" is just a shorthand
for the two repos I push my git repo to (so that I have it on some other
machines too)
[remote "all"]
url = master.kernel.org:git
url = login.linux-foundation.org:git.git
Without any real debugging at all, here's what I get:
error: failed to push to 'master.kernel.org:git'
error: send-pack died with strange error
fatal: The remote end hung up unexpectedly
error: failed to push to 'login.linux-foundation.org:git.git'
error: send-pack died with strange error
fatal: The remote end hung up unexpectedly
and a few core-files. The core-files look like so:
Core was generated by `/home/torvalds/bin/git-send-pack --remote=all --thin master.kernel.org git refs'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000003959477180 in strlen () from /lib64/libc.so.6
(gdb) where
#0 0x0000003959477180 in strlen () from /lib64/libc.so.6
#1 0x000000000041cebe in match_refs (src=0x64b540, dst=<value optimized out>, dst_tail=0x62c890, nr_refspec=1, refspec=<value optimized out>, all=0) at remote.c:539
#2 0x0000000000402e46 in main (argc=<value optimized out>, argv=0x7fffab2657a8) at send-pack.c:202
but I'm about to put the kids to bed, and I doubt I'll get to debug this
before tomorrow. So I thought I'd send this out to Junio, Daniel and the
list, in case somebody else gets to it first.
I *suspect* it's due to the refspec pattern matching changes Daniel did,
but again - I haven't actually debugged it any deeper.
Linus
^ permalink raw reply
* Re: git-send-pack SIGSEGV..
From: Linus Torvalds @ 2007-06-15 4:31 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Daniel Barkalow
In-Reply-To: <alpine.LFD.0.98.0706142124380.14121@woody.linux-foundation.org>
On Thu, 14 Jun 2007, Linus Torvalds wrote:
>
> I haevn't had time to debug this at all, but
>
> git push --tags all
>
> actually SIGSEGV's for me on the git repository.
Oh, and this is with current 'master', of course. Commit 38570a47fc to be
exact.
Linus
^ permalink raw reply
* Re: [CORRECTED PATCH] Introduce file with the common default build-time items.
From: Eygene Ryabinkin @ 2007-06-15 5:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070615032204.GC18491@spearce.org>
Shawn, good da.y
Thu, Jun 14, 2007 at 11:22:04PM -0400, Shawn O. Pearce wrote:
> > OK, it means that git-gui will be totally separated from the
> > git.git? And one will download it as the separate tarball?
>
> That's one option. But Junio and I are also considering keeping
> it inside the git tarball as well, as many users have gotten used
> to it being in the core Git distribution. I think it all depends
> on if myself (or someone else) adds subproject recursion support
> into git-archive. ;-)
OK, I just wondered what to expect from the 1.6, since I am
trying to keep FreeBSD port in sync with the latest Git release.
> ...
> > Makefile | 17 +++++++++++------
> > common-make-vars.def | 11 +++++++++++
> > configure.ac | 4 +++-
> > 3 files changed, 25 insertions(+), 7 deletions(-)
> > create mode 100644 common-make-vars.def
> ...
>
> I dunno. 25 insertions and 7 deletions to reduce two uses of 'wish'
> into one use of 'wish'? That hardly seems worth the additional
> 18 lines of code.
11 of new lines are common-make-vars.def: it is heavily commented.
> Feels like code churn to me. And I rarely feel
> code churn. I'm usually a lot more caviler about changing things
> than Junio, Dscho, Nico, Linus, ...
OK, let us wait for the other's reaction. May be you're right and
it doesn't worth it. But I always felt that if I can change something
by changing it only in one place, then it worth it. Otherwise I
should remember all places where it is used and this leads to errors.
But maybe the 'wish' and 'tclsh' are not worth it.
Thank you!
--
Eygene
^ permalink raw reply
* Re: git-send-pack SIGSEGV..
From: Junio C Hamano @ 2007-06-15 5:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Daniel Barkalow
In-Reply-To: <alpine.LFD.0.98.0706142124380.14121@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I *suspect* it's due to the refspec pattern matching changes Daniel did,
> but again - I haven't actually debugged it any deeper.
I am officially recuperating from an operation I had today, so I
cannot really take a deep look at this.
I think what is going wrong is that struct refspec for pattern
match that is parsed by parse_ref_spec does not have ->dst
component filled for "refs/tags/*" refspec, but match_refs()
does not check if pat->dst is NULL, in which case it should
reuse pat->src value.
Incidentally I have other remote.c fixes queued in 'next'. I
haven't yet checked if I (accidentally) fixed this already.
^ permalink raw reply
* Re: [CORRECTED PATCH] Introduce file with the common default build-time items.
From: Shawn O. Pearce @ 2007-06-15 5:58 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20070615054002.GD3779@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> wrote:
> Thu, Jun 14, 2007 at 11:22:04PM -0400, Shawn O. Pearce wrote:
> > > OK, it means that git-gui will be totally separated from the
> > > git.git? And one will download it as the separate tarball?
> >
> > That's one option. But Junio and I are also considering keeping
> > it inside the git tarball as well, as many users have gotten used
> > to it being in the core Git distribution. I think it all depends
> > on if myself (or someone else) adds subproject recursion support
> > into git-archive. ;-)
>
> OK, I just wondered what to expect from the 1.6, since I am
> trying to keep FreeBSD port in sync with the latest Git release.
Heh. Got a crystal ball?
I'm not sure anyone knows what the 1.6 release will look like yet.
Right now I know we're trying to get the submodule user interface
built and stable, before we start eating that dogfood as part of
the core Git code itself. But we do want to be using our own tools
to build our tools. ;-)
1.6 is just a number thrown on the wall as its likely that by the
time we get around to having a release worthy of the name 1.6 enough
users will be running a 1.5.2 or newer that has at least some of
the basic plumbing and porcelain for subprojects that it wouldn't
be a problem if we started using it ourselves in the git.git project.
--
Shawn.
^ permalink raw reply
* Re: git-send-pack SIGSEGV..
From: Junio C Hamano @ 2007-06-15 6:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Daniel Barkalow
In-Reply-To: <7vvedp935y.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> I *suspect* it's due to the refspec pattern matching changes Daniel did,
>> but again - I haven't actually debugged it any deeper.
>
> I am officially recuperating from an operation I had today, so I
> cannot really take a deep look at this.
>
> I think what is going wrong is that struct refspec for pattern
> match that is parsed by parse_ref_spec does not have ->dst
> component filled for "refs/tags/*" refspec, but match_refs()
> does not check if pat->dst is NULL, in which case it should
> reuse pat->src value.
>
> Incidentally I have other remote.c fixes queued in 'next'. I
> haven't yet checked if I (accidentally) fixed this already.
Completely untested, but this may fix it.
I suspect this has an side effect of allowing
fetch = refs/heads/*
to mean the same thing as
fetch = refs/heads/*:refs/heads/*
which is suitable for a bare mirroring repository, but I do not
think of any downside, so it might be Ok.
But that is something from a person who was under anesthesia a
few hours ago, so you should take it with a big grain of salt ;-)
---
remote.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index ed62a62..356e6bc 100644
--- a/remote.c
+++ b/remote.c
@@ -252,6 +252,8 @@ static struct refspec *parse_ref_spec(int nr_refspec, const char **refspec)
ep = gp;
}
rs[i].src = xstrndup(sp, ep - sp);
+ if (rs[i].pattern && !rs[i].dst)
+ rs[i].dst = xstrdup(rs[i].src);
}
return rs;
}
^ permalink raw reply related
* Re: [CORRECTED PATCH] Introduce file with the common default build-time items.
From: Eygene Ryabinkin @ 2007-06-15 6:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070615055813.GG18491@spearce.org>
Fri, Jun 15, 2007 at 01:58:13AM -0400, Shawn O. Pearce wrote:
> > OK, I just wondered what to expect from the 1.6, since I am
> > trying to keep FreeBSD port in sync with the latest Git release.
>
> Heh. Got a crystal ball?
Sort of: when time will come and new release will be out, various
rumors I heard might help me to get the release to be ported quickly.
At least I hope so ;)
--
Eygene
^ permalink raw reply
* [RFT] Format our Documentation/ with both AsciiDoc 7 & 8
From: Junio C Hamano @ 2007-06-15 6:34 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Stefan Richter
In-Reply-To: <11810823561507-git-send-email-madcoder@debian.org>
It turns out that the attribute definition we have had for a
long time to hide "^" character from AsciiDoc 7 was not honored
by AsciiDoc 8 even under "-a asciidoc7compatible" mode.
Also the double colon at the end of definition list term needs
to be attached to the term, without a whitespace. After this
minimum fixups, AsciiDoc 8 (I used 8.2.1 on Debian) with
compatibility mode seems to produce reasonably good results.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is "Request for Test" to people who reported problems
formatting our documentation with asciidoc 8. To format with
Asciidoc 8, you would need to say something like:
$ make ASCIIDOC8=YesPlease doc
I've compared the output generated with AsciiDoc 7.1.2
without this patch, and generated with AscooDoc 7.1.2 and
AsciiDoc 8.2.1 with this patch. Aside from the expected
obvious differences in:
- embedded Git version string in manpage output
- generation datestamp in HTML output
- autogenerated anchor href="#id" and name="id" in HTML output
the only differences I saw are:
- _word_ is rendered in HTML as <em>word<em> in AsciiDoc 8,
while it used to come out verbatim under AsciiDoc 7. Nice.
- HTML stylesheet is a bit different from AsciiDoc 8.
Presumably an improvement.
Documentation/Makefile | 3 +++
Documentation/asciidoc.conf | 2 +-
Documentation/git-cvsexportcommit.txt | 2 +-
Makefile | 6 ++++++
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 9cef480..4edf788 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -37,6 +37,9 @@ man7dir=$(mandir)/man7
ASCIIDOC=asciidoc
ASCIIDOC_EXTRA =
+ifdef ASCIIDOC8
+ASCIIDOC_EXTRA += -a asciidoc7compatible
+endif
INSTALL?=install
DOC_REF = origin/man
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 99302c5..c135b6e 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -8,7 +8,7 @@
# the command.
[attributes]
-caret=^
+caret=^
startsb=[
endsb=]
tilde=~
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index 827711c..6c423e3 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -76,7 +76,7 @@ $ git-cvsexportcommit -v <commit-sha1>
$ cvs commit -F .mgs <files>
------------
-Merge pending patches into CVS automatically -- only if you really know what you are doing ::
+Merge pending patches into CVS automatically -- only if you really know what you are doing::
+
------------
$ export GIT_DIR=~/project/.git
diff --git a/Makefile b/Makefile
index a70277b..d3b70d2 100644
--- a/Makefile
+++ b/Makefile
@@ -107,6 +107,8 @@ all::
# Define USE_STDEV below if you want git to care about the underlying device
# change being considered an inode change from the update-cache perspective.
#
+# Define ASCIIDOC8 if you want to format documentation with AsciiDoc 8
+#
# Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
# MakeMaker (e.g. using ActiveState under Cygwin).
#
@@ -684,6 +686,10 @@ ifndef V
endif
endif
+ifdef ASCIIDOC8
+ export ASCIIDOC8
+endif
+
# Shell quote (do not use $(call) to accommodate ancient setups);
SHA1_HEADER_SQ = $(subst ','\'',$(SHA1_HEADER))
--
1.5.2.1.280.g38570
^ permalink raw reply related
* Re: git-p4import.py robustness changes
From: Marius Storm-Olsen, mstormo_git @ 2007-06-15 5:30 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <200706142344.29089.simon@lst.de>
[-- Attachment #1: Type: text/plain, Size: 742 bytes --]
Simon Hausmann said the following on 14.06.2007 23:44:
> First of all thanks for looking at the branch. I agree with your
> concerns and I do admit that I've been a bit too sloppy with the
> log messages.
>
> I have started cleaning up the history even more by reworking the
> log messages of my commits (git-p4-enhanced-logs branch in
> fast-export, starting at the last page). Once that is done (I
> expect that to take a few days) I'll add the missing SOB lines with
> git-filter-branch and see if I can get an agreement from Han-Wen
> and Marius for doing the same with their commits (adding the
> missing lines).
Simon,
Of course! Go right ahead and add the SOB for my commits while you're
at it.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation/gitmodules: fix asciidoc
From: Lars Hjemli @ 2007-06-15 7:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Sam Vilain, Junio C Hamano, git
In-Reply-To: <20070615034915.GE18491@spearce.org>
On 6/15/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> > ---
> > I was getting documentation build errors without this
>
> Yea, I got doc build errors today too from `next`
This is my bad, sorry about that.
Have you tested the patch in
<11817720703159-git-send-email-hjemli@gmail.com> /
http://article.gmane.org/gmane.comp.version-control.git/50135 ?
--
larsh
^ 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