* How to import a exist git repository into another git repository?
From: Edmond Halley @ 2011-01-05 6:50 UTC (permalink / raw)
To: git; +Cc: Halley
Hi,
I have two exit repos A and B. I would like A becomes part of B. For example:
original:
A
|-- a.cpp
`-- Makefile
B
|-- b.cpp
`-- Makefile
combined:
B
|-- b.cpp
|-- Makefile
`-- A
|-- a.cpp
`-- Makefile
The git log of repo A is kept in the combined repo.
I try google but the following methods turn out they do not work like
what I want. I can not view the log of original repo A after
combining.
1) http://stackoverflow.com/questions/1683531/how-to-import-existing-git-repository-into-another
Fail at the following command.
git checkout -b ZZZ other/master
error: Untracked working tree file 'Makefile' would be overwritten by merge.
2) http://thread.gmane.org/gmane.comp.version-control.git/5126/
git log only give the lastest commit message. I do not know how to get
the log if orignal repo A.
Thank you!
Best regards,
Halley
^ permalink raw reply
* Re: [minor BUG] cherry-pick -x doesn't work if a conflict occurs
From: Robin Rosenberg @ 2011-01-05 6:31 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20101229141638.GA14865@pengutronix.de>
29 dec 2010 kl. 15:16 skrev Uwe Kleine-König:
> Hello,
>
> when hitting a conflict cherry-pick suggests using
>
> git commit -c $sha1
>
> but the resulting (suggested) commit log doesn't have the extra
> reference requested by -x.
>
The man page says -x only takes effect when you do not have a conflict, so there
is no bug.
-- robin
^ permalink raw reply
* "git svn fetch" on a branch is broken after "git svn reset"
From: Albert Dvornik @ 2011-01-05 6:22 UTC (permalink / raw)
To: git
The documentation for git svn claims that this should work:
git svn reset -r2 -p
git svn fetch
But when I tried it (using an SVN tree that has recent commits only in
a branch, not the trunk), it didn't work correctly. "fetch" grabbed
just the latest version from SVN, and not all revs from <revnum> to
the head! Note that it matters that this is in an SVN branch-- if I
repeat the test using revs in the trunk, everything works as expected.
Specifically, what I did was this:
git co -b testing refs/remotes/test-branch
git svn fetch
git svn reset -r 850
# does correctly rewind to rev 850, undoing commits in test-branch
git svn fetch
# oops, only fetches the *head* revision (rev 856) from SVN!
# In refs/remotes/test-branch, SVN rev 850 is now followed by 856!
I then tried this again, but between reset and fetching I manually
edited .git/svn/.metadata and moved back the *-maxRev versions to 850;
after doing this, the fetch does the right thing. I tried examining
the logic in git-svn.perl to figure out why this happens and why it
would be affecting a branch but not the trunk, but I didn't get very
far.
I can reproduce the problem on Linux (git version 1.7.2.1) and Windows
(Git for Windows version 1.7.3.2.msysgit.0.4.ga4f3f or Cygwin git
1.7.2.3).
Thoughts?
--bert
^ permalink raw reply
* Re: False positives in git diff-index
From: Jeff King @ 2011-01-05 6:15 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git
In-Reply-To: <AANLkTimQCMr+emw=rXdBKKnD_W9G981zCkboKgiDWxPF@mail.gmail.com>
On Wed, Jan 05, 2011 at 06:07:35AM +0000, Alexander Gladysh wrote:
> > Basically, we generate random data which has a 20% chance of
> > being the same as what's there. When it is, we should get "not bothering
> > to commit", but in your error case, we would try to commit (and get "no
> > changes").
>
> > But using that script, I can't replicate your problem. Can you try
> > running it on the same box you're having trouble with? That might at
> > least tell us if it's your environment or something more complex going
> > on.
>
> Thank you. I tried it, and, unfortunately, it does not reproduce the
> problem.
Oh well, thanks for trying.
Going back to your original reproduction recipe, can you change the
"diff-index" line to actually report on what it thinks is different?
That is, drop the "--quiet" and have it actually produce a patch?
It would be interesting to see what is different, and how that compares
with the "git status" you run just prior to it (and whether it matches
the file you "git add"ed just above).
You haven't told us much about your build process. Are you absolutely
sure that there couldn't be another process on the system manipulating
the files between the various runs?
Are you running on top of any special filesystem that might not meet the
consistency guarantees we expect (though in that case, I would assume my
trivial script would have reproduced).
-Peff
^ permalink raw reply
* Re: False positives in git diff-index
From: Alexander Gladysh @ 2011-01-05 6:07 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110105054825.GC5884@sigill.intra.peff.net>
On Wed, Jan 5, 2011 at 05:48, Jeff King <peff@peff.net> wrote:
> On Tue, Jan 04, 2011 at 12:45:33PM +0300, Alexander Gladysh wrote:
>> > Anyway, I'm ready to debug this issue if someone will guide me.
> If adding a sleep makes it work, that sounds like a race condition in
> git. But from the description of your workflow, it should be easy to
> make a minimal example:
> -- 8< --
> Basically, we generate random data which has a 20% chance of
> being the same as what's there. When it is, we should get "not bothering
> to commit", but in your error case, we would try to commit (and get "no
> changes").
> But using that script, I can't replicate your problem. Can you try
> running it on the same box you're having trouble with? That might at
> least tell us if it's your environment or something more complex going
> on.
Thank you. I tried it, and, unfortunately, it does not reproduce the problem.
Alexander.
^ permalink raw reply
* Re: False positives in git diff-index
From: Jeff King @ 2011-01-05 5:48 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git
In-Reply-To: <AANLkTinDSCPz-oukxzn24hj94d9WpzZ8_64TBHeNTmoG@mail.gmail.com>
On Tue, Jan 04, 2011 at 12:45:33PM +0300, Alexander Gladysh wrote:
> > Anyway, I'm ready to debug this issue if someone will guide me.
> >
> > Workflow:
> >
> > <...change files in /path/dir1/...>
> > (cd /path && git add </path/dir1/>)
> > (cd /path && git commit -m <message1>)
> >
> > ... repeat change-add-commit several times for various directories
> > (can be the same directory or not) ...
> >
> > <...generate file /path/dirN/foo...>
> > # Accidentally the file is generated the same as it was
> >
> > (cd /path && git add </path/dirN/>)
> > (cd /path && git status) # Refresh index
> > (cd /path && git diff-index --exit-code --quiet HEAD -- /path/dirN) #
> > Incorrectly reports that there are some changes
> > (cd /path && git commit -m <messageN>) # fails, saying that there is
> > nothing to commit
> >
> > If I insert sleep 10 between git status and git diff-index, the
> > problem goes away.
If adding a sleep makes it work, that sounds like a race condition in
git. But from the description of your workflow, it should be easy to
make a minimal example:
-- >8 --
#!/bin/sh
random() {
perl -e 'print int(rand(5))+1, "\n"'
}
rm -rf repo
mkdir repo && cd repo && git init
for i in 1 2 3 4 5; do
mkdir dir$i
echo initial >dir$i/file
done
git add .
git commit -m initial
while true; do
for i in 1 2 3 4 5; do
random >dir$i/file
git add dir$i
git update-index --refresh
if ! git diff-index --exit-code --quiet HEAD -- dir$i; then
if ! git commit -m foo; then
echo breakage
exit 1
fi
else
echo not bothering to commit
fi
done
done
-- 8< --
Basically, we generate random data which has a 20% chance of
being the same as what's there. When it is, we should get "not bothering
to commit", but in your error case, we would try to commit (and get "no
changes").
But using that script, I can't replicate your problem. Can you try
running it on the same box you're having trouble with? That might at
least tell us if it's your environment or something more complex going
on.
-Peff
^ permalink raw reply
* Re: PostScript files: textconv and "git add -p"
From: Jeff King @ 2011-01-05 5:18 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqy670brcb.fsf@bauges.imag.fr>
On Tue, Jan 04, 2011 at 04:50:44PM +0100, Matthieu Moy wrote:
> If I do this:
>
> ,----[ .gitattributes ]
> | *.ps diff=ps
> `----
>
> ,----[ .gitconfig ]
> | [diff "ps"]
> | textconv=ps2ascii
> `----
>
> then I get the textconv niceness when running "git diff", which is
> cool, but "git add -p" still proposes me to stage hunks one by one,
> which isn't.
>
> If I set "*.ps binary" in .gitattributes, "git add -p" becomes quiet,
> but textconv is disabled.
Yeah the "binary" attribute (which is a synonym for !diff along with
some crlf stuff) and "diff" are mutually exclusive. One says "don't diff
this" and the other says "diff this according to some special rules".
But fortunately, those special rules can contain "this is binary". So
you can get what you want with:
echo '*.ps diff=ps' >.gitattributes
git config diff.ps.textconv ps2ascii
git config diff.ps.binary true
which will textconv the file in the usual places, but consider it binary
in all other circumstances (like "add -p").
-Peff
PS Your question made me very happy. I implemented "diff.*.binary" the
way I did out of a vague sense of orthogonality, but I never quite
came up with a concrete example where it was useful to set both.
Thanks for providing one. :)
^ permalink raw reply
* Re: Tracking branches and pulling on remote
From: Jeff King @ 2011-01-05 5:01 UTC (permalink / raw)
To: Maaartin; +Cc: git
In-Reply-To: <loom.20110105T013525-413@post.gmane.org>
On Wed, Jan 05, 2011 at 12:58:47AM +0000, Maaartin wrote:
> 1.
> I'm using git for couple of months and still don't get it. In a new repo a have
> two branches: master and X. I pushed both to the server, everything seems to
> work. However, there's origin/master but no origin/X in my repo. When I execute
> git fetch --all -v
> only master gets fetched. I've created an entry in the .git/config, no change.
> I've tried things like
> git branch --track X origin/X
> and all of them ends with an error message. Finally I've found out that
> git config --add remote.origin.fetch refs/heads/X:refs/remotes/origin/X
> seems to do it, was it right?
There should already have been a remote.origin.fetch that looked like:
$ git config remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
which is a superset of what you added. If you run the git config command
I did above, what do you see? If you have a wildcard line like the one
above (which is added during the initial clone), then the config you
added would have done nothing.
Are you absolutely sure that the branch was pushed to the remote side in
the first place? How did you push it?
> 2.
> I'd like to do some (at least for now) private changes on a foreign project. The
> ideal way I think about would be the following:
> - my local repo is linked to my own server (for backup purposes and for private
> cooperation with a college)
> - the repo on my server is linked to the github hosting the project
> Now, I'd need to do something like
> ssh myserver git fetch
> and everything would be fine. I can do it this way, but I'd prefer something like
> git remote fetch
> or even
> git fetch --remote-too
> which would first make my server fetch from its origin and then my local repo
> fetch from my server. Is there such a thing? Would you recommend me doing it in
> a different way?
There isn't really a shortcut for the two-level thing you're trying to
do. But consider rearranging your topology to always pull to the local
repo, and then push changes up to your backup/collaboration server.
Something like:
$ git clone http://github.com/whatever/project.git
$ cd project
$ git remote add myserver myserver:/path/to/backup repo
and then your workflow is:
: hmm, I feel like working on project. what happened upstream?
$ git pull ;# or git fetch origin; gitk origin... ; git merge origin
$ hack hack hack
: ok, now I have some work to show to my collaborator
$ git push myserver
or possibly:
: ok, now what has my collaborator been up to
$ git fetch myserver
$ gitk myserver/topic
: I like it, let's merge
$ git merge myserver/topic
: Now push back my merge
$ git push myserver
You might also find it convenient to swap which remote is "origin"
(since it is the default for "git push" without arguments). That is, you
primarily consider your local repo to be a clone of what's on
"myserver", but you occasionally fetch and merge changes from upstream,
like:
: ok, what has my collaborator been working on?
$ git pull
: and what has upstream been up to?
$ git fetch upstream
: oh, neat stuff. let's merge it
$ git merge upstream
: and then let's publish it so our collaborator will also work on top
: of it
$ git push ;# implicitly to origin
How you want to set it up really depends on which mental model
represents your workflow best.
-Peff
^ permalink raw reply
* Re: [PATCH 00/31] Refactor rebase
From: Martin von Zweigbergk @ 2011-01-05 3:39 UTC (permalink / raw)
To: Thomas Rast
Cc: Martin von Zweigbergk, git, Junio C Hamano, Johannes Schindelin,
Johannes Sixt, Christian Couder
In-Reply-To: <201101042057.29809.trast@student.ethz.ch>
On Tue, 4 Jan 2011, Thomas Rast wrote:
> Martin von Zweigbergk wrote:
> > For the past two months, I have been working on refactoring the rebase
> > code. See [1] for background information. I have been trying to polish
> > the patch set for some time, but now I don't think I will get much
> > further without your help.
>
> Thanks a lot for undertaking this effort! I just finished looking
> through the entire series, and it all seems sane to me. Apart from
> j6t's reply I think we're mostly nit-picking or agreeing with you, and
> this is the first iteration!
Thanks. And thanks a lot for taking the time to review it!
/Martin
^ permalink raw reply
* Re: [PATCH 26/31] rebase: remember strategy and strategy options
From: Martin von Zweigbergk @ 2011-01-05 3:33 UTC (permalink / raw)
To: Thomas Rast
Cc: Martin von Zweigbergk, git, Junio C Hamano, Johannes Schindelin,
Johannes Sixt, Christian Couder
In-Reply-To: <201101042027.26737.trast@student.ethz.ch>
On Tue, 4 Jan 2011, Thomas Rast wrote:
> Martin von Zweigbergk wrote:
> > How to add support for strategy options to interactive rebase?
>
> AFAICS rebase -i currently only uses the strategy when dealing with
> multiple parents, i.e., in --preserve-merges mode. I think
> git-cherry-pick needs to learn about the -s and -X options, and then
> it'll be a simple matter of passing them along.
I just saw that Jonathan has actually implemented that support in
git-cherry-pick. It is currently in pu.
I asked just because the merge strategy is currently passed to the
call to 'git merge' in git-rebase--interactive.sh (when dealing with
multiple parents, as you said), so it seems like it would make sense
to pass any merge options there as well.
Come to think of it, doesn't the merge option when passed to 'git
rebase -i' mean something quite different compared to when it is
passed to 'git rebase -m'? For interactive rebase, the 'ours' side
refers to the upstream, but in the case of merge-based rebase, it
refers to one branch in the branch-to-be-rebased, no? In that case,
should the merge strategy even be passed to 'git merge' when dealing
with multiple parents? Is it likely that one would want to use the
same strategy for both things? Am I just not thinking straight?
Some history:
The command line option '-s' was there from the inception of
interactive rebase in 1b1dce4 (Teach rebase an interactive mode,
2007-06-25) and back then it was passed to git-cherry-pick, which just
ignored it.
Since f09c9b8 (Teach rebase -i about --preserve-merges, 2007-06-25),
the strategy has been passed to git-merge as well.
Since 2a9c53e (git-rebase--interactive.sh: Don't pass a strategy to
git-cherry-pick., 2007-10-31), the strategy has only been passed to
git-merge, because it was ignored by git-cherry-pick.
Anyway, I'll leave any changes related to this outside of the current
series.
/Martin
^ permalink raw reply
* Re: [PATCH 24/31] rebase: extract code for writing basic state
From: Martin von Zweigbergk @ 2011-01-05 2:40 UTC (permalink / raw)
To: Thomas Rast
Cc: Martin von Zweigbergk, git, Junio C Hamano, Johannes Schindelin,
Johannes Sixt, Christian Couder
In-Reply-To: <201101042019.24223.trast@student.ethz.ch>
On Tue, 4 Jan 2011, Thomas Rast wrote:
> Martin von Zweigbergk wrote:
> > Note that non-interactive rebase stores the sha1 of the original head
> > in a file called orig-head, while interactive rebase stores it in a
> > file called head.
> [...]
> > + if test "$type" = interactive
> > + then
> > + echo "$orig_head" > "$state_dir"/head
> > + else
> > + echo "$orig_head" > "$state_dir"/orig-head
> > + fi &&
>
> Do we have to cater to the use-case where the user starts a rebase,
> downgrades at a conflict, and then continues?
I'll let Junio answer that.
> If not, you could read 'orig-head' first and fall back to 'head', only
> writing 'orig-head' in the state saving independent of the mode. That
> would give us the chance of removing the redundancy at some point.
Makes sense. Given that the answer to the previous question is a "no",
I'll change this as well in the next iteration.
/Martin
^ permalink raw reply
* Re: [PATCH 08/31] rebase: align variable names
From: Martin von Zweigbergk @ 2011-01-05 2:25 UTC (permalink / raw)
To: Thomas Rast
Cc: Martin von Zweigbergk, git, Junio C Hamano, Johannes Schindelin,
Johannes Sixt, Christian Couder
In-Reply-To: <201101042012.25580.trast@student.ethz.ch>
On Tue, 4 Jan 2011, Thomas Rast wrote:
> Martin von Zweigbergk wrote:
> > Use the same names for variables that git-rebase--interactive.sh will
> > soon inherit from git-rebase.sh.
>
> AFAICS this is partly about spelling the variables in lowercase
> instead of all-caps.
>
> Wouldn't it be nicer to simply downcase *all* variables, so that the
> end result has a consistent coding style?
Yes, it would :-). I was just being conservative by trying not to
touch code that I didn't have to touch. I'll rename the remaining
variables in the next iteration.
Thanks,
Martin
^ permalink raw reply
* [RFC PATCH 11/9] [PoC] gitweb/lib - HTTP-aware output caching
From: Jakub Narebski @ 2011-01-05 2:26 UTC (permalink / raw)
To: git; +Cc: J.H., John 'Warthog9' Hawley
In-Reply-To: <20101222234843.7998.87068.stgit@localhost.localdomain>
This commit adds new option, -http_output, to cache_output()
subroutine from GitwebCache::CacheOutput module. When this subroutine
is called as cache_output(..., -http_output => 1), it assumes that
cached output is HTTP response, consisting of HTTP headers separated
by CR LF pair from the HTTP body (contents of the page). It adds then
Expires and Cache-Control: max-age headers if they do not exist based
on current cache entry expiration time, and Content-Length header
based on the size of cache entry file.
New subtest in t9512 includes basic tests for this feature.
Enable it in gitweb, via $cache_options{'cache_output'} hashref.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch is intended as proof of concept about making output caching
in gitweb make use of the fact that we cache HTTP response. In this
patch the "smarts" (the "HTTP awareness") was added to the part of code
responsible by sending response to client. Alternate solution would
be to add such "smarts" to saving captured output to cache file, or even
to caching engine itself. Each of those solutions has its advantages
and disadvantages.
J.H., among others this patch is meant to illustrate that you don't need
treat output of 'snapshot' and 'blob_plain' views in a special way; you
can add Content-Length header in a action-agnostic way.
This patch replaces controversial "[RFC PATCH v7 11/9] [PoC] gitweb/lib
- tee, i.e. print and capture during cache entry generation" for
simplicity, though it is fairly independent, and probably would apply
without problems after it.
NOTE: This is only RFC, and while it passes t9512, I haven't done extensive
testing with it.
gitweb/gitweb.perl | 3 ++
gitweb/lib/GitwebCache/CacheOutput.pm | 32 ++++++++++++++++++++++++
gitweb/lib/GitwebCache/FileCacheWithLocking.pm | 24 ++++++++++++++++++
t/t9512/test_cache_output.pl | 25 ++++++++++++++++++
4 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e3f02b0..f3c14a9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -360,6 +360,9 @@ our %cache_options = (
# pages will be cached if were generated in detached process).
# Default is undef.
'-cache_errors' => undef,
+ # Mark that we are caching HTTP response, and that we want extra treatment,
+ # i.e. automatic adding of Expires/Cache-Control and Content-Length headers
+ '-http_output' => 1,
},
);
# You define site-wide options for "Generating..." page (if enabled) here
diff --git a/gitweb/lib/GitwebCache/CacheOutput.pm b/gitweb/lib/GitwebCache/CacheOutput.pm
index 188d4ab..e9884ca 100644
--- a/gitweb/lib/GitwebCache/CacheOutput.pm
+++ b/gitweb/lib/GitwebCache/CacheOutput.pm
@@ -19,6 +19,7 @@ use warnings;
use File::Copy qw();
use Symbol qw(qualify_to_ref);
+use CGI::Util qw(expires);
use Exporter qw(import);
our @EXPORT = qw(cache_output);
@@ -69,6 +70,37 @@ sub cache_output {
$filename ||= $capture_filename;
}
+ if ($opts{'-http_output'}) {
+ # we need filehandle; filename is not enough
+ open $fh, '<', $filename unless defined $fh;
+
+ # get HTTP headers first
+ my (@headers, %norm_headers);
+ while (my $line = <$fh>) {
+ last if $line eq "\r\n";
+ push @headers, $line;
+ if ($line =~ /^([^:]+:)\s+(.*)$/) {
+ (my $header = lc($1)) =~ s/_/-/;
+ $norm_headers{$header} = $2;
+ }
+ }
+ print join('', @headers);
+
+ # extra headers
+ if (!exists $norm_headers{lc('Expires')} &&
+ !exists $norm_headers{lc('Cache-Control')}) {
+ my $expires_in = $cache->expires_in($key);
+ print "Expires: " . expires($expires_in, 'http')."\r\n".
+ "Cache-Control: max-age=$expires_in\r\n";
+ }
+ if (!exists $norm_headers{lc('Content-Length')}) {
+ my $length = (-s $fh) - (tell $fh);
+ print "Content-Length: $length\r\n" if $length;
+ }
+
+ print "\r\n"; # separates headers from body
+ }
+
if (defined $fh || defined $filename) {
# set binmode only if $fh is defined (is a filehandle)
# File::Copy::copy opens files given by filename in binary mode
diff --git a/gitweb/lib/GitwebCache/FileCacheWithLocking.pm b/gitweb/lib/GitwebCache/FileCacheWithLocking.pm
index 291526e..813331a 100644
--- a/gitweb/lib/GitwebCache/FileCacheWithLocking.pm
+++ b/gitweb/lib/GitwebCache/FileCacheWithLocking.pm
@@ -457,6 +457,30 @@ sub is_valid {
return (($now - $mtime) < $expires_in);
}
+# $cache->expires_in($key)
+#
+# Returns number of seconds an entry would be valid, or undef
+# if cache entry for given $key does not exists.
+sub expires_in {
+ my ($self, $key) = @_;
+
+ my $path = $self->path_to_key($key);
+
+ # does file exists in cache?
+ return undef unless -f $path;
+ # get its modification time
+ my $mtime = (stat(_))[9] # _ to reuse stat structure used in -f test
+ or $self->_handle_error("Couldn't stat file '$path' for key '$key': $!");
+
+ my $expires_in = $self->get_expires_in();
+
+ my $now = time();
+ print STDERR __PACKAGE__."now=$now; mtime=$mtime; ".
+ "expires_in=$expires_in; diff=".($now - $mtime)."\n";
+
+ return $expires_in == 0 ? 0 : ($self->get_expires_in() - ($now - $mtime));
+}
+
# Getting and setting
# ($fh, $filename) = $cache->compute_fh($key, $code);
diff --git a/t/t9512/test_cache_output.pl b/t/t9512/test_cache_output.pl
index 758848c..3492dcf 100755
--- a/t/t9512/test_cache_output.pl
+++ b/t/t9512/test_cache_output.pl
@@ -6,6 +6,8 @@ use strict;
use Test::More;
+use CGI qw(:standard);
+
# test source version
use lib $ENV{GITWEBLIBDIR} || "$ENV{GIT_BUILD_DIR}/gitweb/lib";
@@ -158,5 +160,28 @@ subtest 'errors are cached with -cache_errors => 1' => sub {
};
+# caching HTTP output
+subtest 'HTTP output' => sub {
+ $cache->remove($key);
+ $cache->set_expires_in(60);
+
+ my $header =
+ header(-status=>'200 OK', -type=>'text/plain', -charset => 'utf-8');
+ my $data = "1234567890";
+ $action_output = $header.$data;
+ $test_data = capture_output_of_cache_output(\&action, '-http_output' => 1);
+
+ $header =~ s/\r\n$//;
+ my $length = do { use bytes; length($data); };
+ like($test_data, qr/^\Q$header\E/, 'http: starts with provided http header');
+ like($test_data, qr/\Q$data\E$/, 'http: ends with body (payload)');
+ like($test_data, qr/^Expires: /m, 'http: some "Expires:" header added');
+ like($test_data, qr/^Cache-Control: max-age=\d+\r\n/m,
+ 'http: "Cache-Control:" with max-age added');
+ like($test_data, qr/^Content-Length: $length\r\n/m,
+ 'http: "Content-Length:" header with correct value');
+};
+
+
done_testing();
__END__
--
1.7.3
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2011, #01; Tue, 4)
From: Martin von Zweigbergk @ 2011-01-05 2:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vipy4dy8y.fsf@alter.siamese.dyndns.org>
On Tue, 4 Jan 2011, Junio C Hamano wrote:
> A happy new year.
Indeed.
> I'll start paying much less attention to any new features and enhancements
> and shift the focus almost entirely on trivial fixes and regressions from
> now on. Hopefully lists will do the same and we can have a fairly short
> rc period this cycle. Please remind if there are patches that ought to be
> in 1.7.4 but are forgotten.
I noticed that my rebase refactoring patches are no longer in pu. Is
this (the above) why? They were not mentioned in the previous "What's
cooking" either, even though they were in pu at that time. It is not
quite clear to me which topics are mentioned in "What's cooking" and
which are not. I see that not all topics in pu right now are mentioned
in today's "What's cooking" either.
Regards,
Martin
^ permalink raw reply
* patch for git-p4
From: Andrew Garber @ 2011-01-05 1:45 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 327 bytes --]
Hi everyone! This is my first post to the git mailing list.
I was reading the git-p4 source and noticed that some of the lines are
indented using tabs instead of spaces (very bad in Python). Here's a
patch against tag v1.7.4-rc0 (commit
01b97a4cb60723d18b437efdc474503d2a9dd384) of the git source repo.
Thanks!
Andrew Garber
[-- Attachment #2: git-p4_tabs_to_spaces.patch --]
[-- Type: application/octet-stream, Size: 5057 bytes --]
From ce7ff27529bb5ec608ba6b6a841ce2f3ce605a3c Mon Sep 17 00:00:00 2001
From: Andrew Garber <andrew@andrewgarber.com>
Date: Wed, 29 Dec 2010 00:23:05 -0800
Subject: [PATCH] git-p4: replaced tabs with spaces
Some the commits to git-p4 used tabs for indenting instead of spaces. I
also did some minor reformatting.
---
contrib/fast-import/git-p4 | 71 +++++++++++++++++++++-----------------------
1 files changed, 34 insertions(+), 37 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 04ce7e3..449df2e 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -222,10 +222,10 @@ def p4CmdList(cmd, stdin=None, stdin_mode='w+b', cb=None):
try:
while True:
entry = marshal.load(p4.stdout)
- if cb is not None:
- cb(entry)
- else:
- result.append(entry)
+ if cb is not None:
+ cb(entry)
+ else:
+ result.append(entry)
except EOFError:
pass
exitCode = p4.wait()
@@ -445,8 +445,8 @@ def p4ChangesForPaths(depotPaths, changeRange):
changes = {}
for line in output:
- changeNum = int(line.split(" ")[1])
- changes[changeNum] = True
+ changeNum = int(line.split(" ")[1])
+ changes[changeNum] = True
changelist = changes.keys()
changelist.sort()
@@ -954,10 +954,9 @@ class P4Sync(Command):
# - helper for streamP4Files
def streamOneP4File(self, file, contents):
- if file["type"] == "apple":
- print "\nfile %s is a strange apple file that forks. Ignoring" % \
- file['depotFile']
- return
+ if file["type"] == "apple":
+ print "\nfile %s is a strange apple file that forks. Ignoring" % file['depotFile']
+ return
relPath = self.stripRepoPath(file['depotFile'], self.branchPrefixes)
if verbose:
@@ -1004,23 +1003,22 @@ class P4Sync(Command):
# handle another chunk of streaming data
def streamP4FilesCb(self, marshalled):
+ if marshalled.has_key('depotFile') and self.stream_have_file_info:
+ # start of a new file - output the old one first
+ self.streamOneP4File(self.stream_file, self.stream_contents)
+ self.stream_file = {}
+ self.stream_contents = []
+ self.stream_have_file_info = False
- if marshalled.has_key('depotFile') and self.stream_have_file_info:
- # start of a new file - output the old one first
- self.streamOneP4File(self.stream_file, self.stream_contents)
- self.stream_file = {}
- self.stream_contents = []
- self.stream_have_file_info = False
-
- # pick up the new file information... for the
- # 'data' field we need to append to our array
- for k in marshalled.keys():
- if k == 'data':
- self.stream_contents.append(marshalled['data'])
- else:
- self.stream_file[k] = marshalled[k]
+ # pick up the new file information... for the
+ # 'data' field we need to append to our array
+ for k in marshalled.keys():
+ if k == 'data':
+ self.stream_contents.append(marshalled['data'])
+ else:
+ self.stream_file[k] = marshalled[k]
- self.stream_have_file_info = True
+ self.stream_have_file_info = True
# Stream directly from "p4 files" into "git fast-import"
def streamP4Files(self, files):
@@ -1052,23 +1050,22 @@ class P4Sync(Command):
self.stream_contents = []
self.stream_have_file_info = False
- # curry self argument
- def streamP4FilesCbSelf(entry):
- self.streamP4FilesCb(entry)
+ # curry self argument
+ def streamP4FilesCbSelf(entry):
+ self.streamP4FilesCb(entry)
- p4CmdList("-x - print",
- '\n'.join(['%s#%s' % (f['path'], f['rev'])
- for f in filesToRead]),
- cb=streamP4FilesCbSelf)
+ p4CmdList("-x - print",
+ '\n'.join(['%s#%s' % (f['path'], f['rev']) for f in filesToRead]),
+ cb=streamP4FilesCbSelf)
- # do the last chunk
- if self.stream_file.has_key('depotFile'):
- self.streamOneP4File(self.stream_file, self.stream_contents)
+ # do the last chunk
+ if self.stream_file.has_key('depotFile'):
+ self.streamOneP4File(self.stream_file, self.stream_contents)
def commit(self, details, files, branch, branchPrefixes, parent = ""):
epoch = details["time"]
author = details["user"]
- self.branchPrefixes = branchPrefixes
+ self.branchPrefixes = branchPrefixes
if self.verbose:
print "commit into %s" % branch
@@ -1173,7 +1170,7 @@ class P4Sync(Command):
s = ''
for (key, val) in self.users.items():
- s += "%s\t%s\n" % (key.expandtabs(1), val.expandtabs(1))
+ s += "%s\t%s\n" % (key.expandtabs(1), val.expandtabs(1))
open(self.getUserCacheFilename(), "wb").write(s)
self.userMapFromPerforceServer = True
--
1.7.3.2
^ permalink raw reply related
* Re: Web browser and Git wiki (kernel.org) not getting along....
From: Maaartin @ 2011-01-05 1:05 UTC (permalink / raw)
To: git
In-Reply-To: <4D20301F.5050002@kernel.org>
J.H. <warthog9 <at> kernel.org> writes:
> On 01/01/2011 08:16 PM, Drew Northup wrote:
> > Are any other Opera users getting this error when attempting to go to
> > https://git.wiki.kernel.org ?
>
> Known bug in Opera, the problem lies in how it handles wild card
> certificates. It is claimed to be fixed in the next version by another
> user who has pushed the issue with Opera.
That's true, I'm using Opera 11.00 (under Windows XP) and it works now fine.
^ permalink raw reply
* Tracking branches and pulling on remote
From: Maaartin @ 2011-01-05 0:58 UTC (permalink / raw)
To: git
1.
I'm using git for couple of months and still don't get it. In a new repo a have
two branches: master and X. I pushed both to the server, everything seems to
work. However, there's origin/master but no origin/X in my repo. When I execute
git fetch --all -v
only master gets fetched. I've created an entry in the .git/config, no change.
I've tried things like
git branch --track X origin/X
and all of them ends with an error message. Finally I've found out that
git config --add remote.origin.fetch refs/heads/X:refs/remotes/origin/X
seems to do it, was it right?
2.
I'd like to do some (at least for now) private changes on a foreign project. The
ideal way I think about would be the following:
- my local repo is linked to my own server (for backup purposes and for private
cooperation with a college)
- the repo on my server is linked to the github hosting the project
Now, I'd need to do something like
ssh myserver git fetch
and everything would be fine. I can do it this way, but I'd prefer something like
git remote fetch
or even
git fetch --remote-too
which would first make my server fetch from its origin and then my local repo
fetch from my server. Is there such a thing? Would you recommend me doing it in
a different way?
^ permalink raw reply
* Re: [PATCH 2/4] gitweb: remove unnecessary test when closing file descriptor
From: Jakub Narebski @ 2011-01-05 0:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sylvain Rabot, git
In-Reply-To: <7vaajgdx35.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sylvain Rabot <sylvain@abstraction.fr> writes:
>
> > it happens that closing file descriptor fails whereas
> > the blob is perfectly readable. According to perlman
> > the reasons could be:
> >
> > If the file handle came from a piped open, "close" will additionally
> > return false if one of the other system calls involved fails, or if the
> > program exits with non-zero status. (If the only problem was that the
> > program exited non-zero, $! will be set to 0.) Closing a pipe also waits
> > for the process executing on the pipe to complete, in case you want to
> > look at the output of the pipe afterwards, and implicitly puts the exit
> > status value of that command into $?.
> >
> > Prematurely closing the read end of a pipe (i.e. before the process writ-
> > ing to it at the other end has closed it) will result in a SIGPIPE being
> > delivered to the writer. If the other end can't handle that, be sure to
> > read all the data before closing the pipe.
> >
> > In this case we don't mind that close fails.
> >
> > Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
>
> Hmm, do you want a few helped-by lines here?
>
> I'll queue this to 'pu', but only because I do not care too much about
> this part of the codepath, not because I think this is explained well.
True, I might now agree with code, but I still don't like the
explanation...
>
> For example, what does "the reasons could be" mean? If the reasons turned
> out to be totally different, that would make this patch useless? IOW, is
> it fixing the real issue? Without knowing the reasons, how can we
> conclude that "In this case" we don't mind?
Well, "in this case" of run_highlighter() we close filehandle from
git-cat-file, which was used only to test if it passes -T test (file
is an ASCII text file (heuristic guess)), to _reopen_ it with
highlighter as a filter.
Also, with test if failed for Sylvain, with test removed it works all
right.
> Having said all that, I agree that you are seeing a failure exactly
> because of the reason you stated above with an unnecessary weak "could
> be". A filehandle to a pipe to cat-file is opened by the caller of
> blob_mimetype(), it gets peeked at with -T inside the function, then it
> gets peeked at with -B inside the caller (by the way, didn't anybody find
> this sloppy? Why isn't blob_mimetype() doing all of that itself?), and
I think the -B test is here because -T test is last resort in
blob_mimetype; depending on used mime.types one can get something
other than application/octet-stream for non-text file. But I agree
that it could have been done better.
> then after that the run_highligher closes the filehandle, because it does
> not want to read from the unadorned cat-file output at all. Of course,
> cat-file may receive SIGPIPE if we do that, and we know we don't care how
> cat-file died in that particular case.
>
> But do we care if the first cat-file died due to some other reason? Is
> there anything that catches the failure mode?
Well, the alternate would be to examine $! or %!, e.g.
> > @@ -3465,8 +3465,7 @@ sub run_highlighter {
> > my ($fd, $highlight, $syntax) = @_;
> > return $fd unless ($highlight && defined $syntax);
> >
> > close $fd
> > - or die_error(404, "Reading blob failed");
> > + or $!{EPIPE} or die_error(404, "Reading blob failed");
> > open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
> > quote_command($highlight_bin).
> > " --xhtml --fragment --syntax $syntax |"
Though this version is cryptic (but compact).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: developing a modified Linux-style workflow
From: Neal Kreitzinger @ 2011-01-05 0:47 UTC (permalink / raw)
Cc: git, Neal Kreitzinger
In-Reply-To: <4D238EDC.9000503@gmail.com>
On 1/4/2011 3:19 PM, Neal Kreitzinger wrote:
> On 1/4/2011 1:01 PM, Hans-Christoph Steiner wrote:
>>
>> On Dec 13, 2010, at 11:16 AM, Neal Kreitzinger wrote:
>>
>>> "Hans-Christoph Steiner" <hans@at.or.at> wrote in message
>>> news:7EAE16CF-A9A8-47A6-9294-3646CCDB0E9C@at.or.at...
>>>>
>>>> Hey all,
>>>>
>>>> (and my second post on this list...)
>>>>
>>>> I've gotten pretty good at git, and its helping me already with
>>>> managing
>>>> the very odd workflows I have with the software I work a lot on
>>>> called Pd
>>>> (http://puredata.info). My role in Pd development is like a Linux
>>>> lieutenant.
>>>>
>>>> I also the main dev for an app called Pd-extended, which is based on
>>>> Pd.
>>>> Now I'm stuck trying to figure out how to use git to match my current
>>>> workflow for Pd-extended, which is a kind of long-lived branch, almost
>>>> like a friendly fork. So its kind of close to the Linux workflow
>>>> with me
>>>> as a lieutenant, but not quite.
>>>>
>>>> What makes it tricky is that I make releases directly from my repo that
>>>> are widely used. So my repo is both lieutenant and dictator at the same
>>>> time. So that's where I am stumped. I want to be able to rebase and
>>>> push to a public repo, but that would be stupid. So there has got to be
>>>> another way.
>>>>
>>>> .hc
>>>>
>>> I don't think pushing to a public repo is stupid. You could create a
>>> bare
>>> repo with a Pd branch and Pd-extended branch that contain the production
>>> versions of Pd and Pd-extended. The main reason our shop chose git is
>>> because it allows us to easily have multiple concurrent versions of
>>> production by having a branch for each of our custom versions. These
>>> versions eventually get merged together into a major release, but in the
>>> meantime they are longlived branches representing the productional
>>> customized system for each major customer.
>>>
>>> *If* you end up merging Pd and Pd-extended at some point, then you could
>>> have another branch for that, e.g. master or Pd-master or whatever. BTW,
>>> you do not have to use master as the representative of your final merged
>>> work so don't think that is the way you HAVE to do it. It's just the
>>> default, and a common practice for systems with a single version of
>>> production. Master can become vestigial or secondary, if you choose to
>>> create a new branch called Pd-master, etc. to represent your eventual
>>> merges
>>> of Pd and Pd-extended.
>>
>>
>> For me the biggest feature that I am looking for is the automatic
>> merging of commits, and second, having a branch that puts my collection
>> of patches/commits ahead of the Pd master so that its easy to manage the
>> patches. I don't think I see how I could do that with this multiple
>> branches idea. Is that possible?
>>
>
> I have _no_ experience using patches (in git or otherwise) to manage
> change control, ie. git-am, git-format-patch, etc., as of yet...
>
> That being said, FWIW, here is a suggestion based on the following
> assumptions:
>
> a. It sounds like Pd and Pd-extended only get merged once-in-a-while
> (infrequently).
> b. Pd is the main version in use, and Pd-extended is a future version or
> a not-yet-widely-used version.
> c. Pd-extended is based on Pd, but since the inception of Pd-extended
> both Pd and Pd-extended have advanced (diverged).
>
>
> Assuming that is the case, this is similar to what our shop does. We
> have a production system X12 and a new system X13 that is based on X12.
> Periodically, bugfixes and enhancements from X12 need to be merged into
> X13. Here's how we do it:
>
> 1. Identify the range of commits in X12 that are not yet in X13 (new X12
> commits since the last X12-X13 merge):
> $ git log
> sha1-of-last-X12-commit-alreadyMERGED-into-X13..sha1-of-newest-X12-commit-you-want-MERGED-into-X13
> --format="%h%d %s"
> >/somepath/whereIkeepstuff/X12-X13-MRG.01-REBASE-TO-DO.lst
> 2. Identify any commits in the X12 commits that you do not want merged
> into X13.
> 3. Create a throw-away-integration-branch which is a copy of X12:
> $ git checkout X12
> $ git branch X12-Squash
> 4. Create a throw-away-integration-branch which is a copy of X13:
> $ git checkout X13
> $ git branch X13-Merge-X12 <-------corrected typo here
> 5. Squash the X12 merge series into a single commit:
> $ git checkout X12-Squash
> $ git reset --hard sha1-of-newest-X12-commit-you-want-MERGED-into-X13
> (in case its not the head commit of the branch)
> $ git rebase -i sha1-of-last-X12-commit-alreadyMERGED-into-X13
> (interactive rebase to squash the X12 "new commits" series)
> #comment out any commits that you don't want in X13, if applicable.
> put an "s" next to all the other commits to squash them.
> 6. Cherry pick the X12 squashed commit onto X13:
> $ git checkout X13-Merge-X12
> $ git cherry-pick --edit X12-Squash
> resolve any conflicts
> review what got merged automatically and make sure its right (git
> doesn't know about conflicts in logic)
> 7. Merge results into real X13:
> $ git checkout X13
> $ git merge --ff-only X13-Merge-X12
> 8. Create a test copy of the bare repo of X13:
> $ cp -rvp X13.git QA-X13.git
> 9. Push to QA copy of X13 repo: (make sure your push results are ok)
> $ git push QA-X13-remotename HEAD
> review in gitk, etc. to verify it is correct
> 10. Push to real X13 repo:
> $ git push X13-remotename HEAD
> review results
> notify others of update.
>
> Note: you can have X12 and X13 in separate bare repos if you want, or as
> branches in a single bare repo. If X12 and X13 are in separate bare
> repos, then you can use an 'integration manager' repo to remote to them
> and pull their changes into integration branches. That's actually how
> our shop currently does it because the X13 people do not maintain X12.
> The steps above are for a single bare repo in order to save on the
> number of steps in the example.
>
> Hope this helps. If my assumptions are incorrect then we might have
> other merge techniques that may be applicable...
see note on corrected typo above!
v/r,
Neal
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: skip logo in atom feed when there is none
From: Junio C Hamano @ 2011-01-05 0:45 UTC (permalink / raw)
To: Jakub Narebski
Cc: Jonathan Nieder, git, John 'Warthog9' Hawley, Eric Wong
In-Reply-To: <201101050125.52824.jnareb@gmail.com>
Thanks, all.
^ permalink raw reply
* [PATCH] quote.h: simplify the inclusion
From: Jonathan Nieder @ 2011-01-05 0:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Attempting to include quote.h without first including strbuf.h results
in warnings:
./quote.h:33:33: warning: ‘struct strbuf’ declared inside parameter list
./quote.h:33:33: warning: its scope is only this definition or declaration, which is probably not what you want
./quote.h:34:34: warning: ‘struct strbuf’ declared inside parameter list
...
Add a toplevel declaration for struct strbuf to avoid this.
While at it, stop including system headers from quote.h. git source
files already need to include git-compat-util.h sooner to ensure the
appropriate feature test macros are defined.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Noticed while trying to use quote.h in a source file without strbufs.
quote.h | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/quote.h b/quote.h
index 38003bf..024e21d 100644
--- a/quote.h
+++ b/quote.h
@@ -1,8 +1,7 @@
#ifndef QUOTE_H
#define QUOTE_H
-#include <stddef.h>
-#include <stdio.h>
+struct strbuf;
/* Help to copy the thing properly quoted for the shell safety.
* any single quote is replaced with '\'', any exclamation point
--
1.7.4.rc0
^ permalink raw reply related
* Re: [PATCH 1/2] gitweb: skip logo in atom feed when there is none
From: Jakub Narebski @ 2011-01-05 0:25 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, John 'Warthog9' Hawley, Eric Wong
In-Reply-To: <20110104050247.GB8280@burratino>
Jonathan Nieder wrote:
> Date: Fri, 3 Sep 2010 19:44:39 -0500
>
> With v1.5.0-rc0~169 (gitweb: Fix Atom feed <logo>: it is $logo,
> not $logo_url, 2006-12-04), the logo URI to be written to Atom
> feeds was corrected but the case of no logo forgotten.
>
> Acked-by: Eric Wong <normalperson@yhbt.net>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Good catch. As an obvious bugfix:
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 4779618..c65af1a 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -7169,7 +7169,7 @@ XML
> if (defined $favicon) {
> print "<icon>" . esc_url($favicon) . "</icon>\n";
> }
> - if (defined $logo_url) {
> + if (defined $logo) {
> # not twice as wide as tall: 72 x 27 pixels
> print "<logo>" . esc_url($logo) . "</logo>\n";
> }
> --
> 1.7.4.rc0
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/4] gitweb: remove unnecessary test when closing file descriptor
From: Junio C Hamano @ 2011-01-05 0:15 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git
In-Reply-To: <1293744031-17790-3-git-send-email-sylvain@abstraction.fr>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> it happens that closing file descriptor fails whereas
> the blob is perfectly readable. According to perlman
> the reasons could be:
>
> If the file handle came from a piped open, "close" will additionally
> return false if one of the other system calls involved fails, or if the
> program exits with non-zero status. (If the only problem was that the
> program exited non-zero, $! will be set to 0.) Closing a pipe also waits
> for the process executing on the pipe to complete, in case you want to
> look at the output of the pipe afterwards, and implicitly puts the exit
> status value of that command into $?.
>
> Prematurely closing the read end of a pipe (i.e. before the process writ-
> ing to it at the other end has closed it) will result in a SIGPIPE being
> delivered to the writer. If the other end can't handle that, be sure to
> read all the data before closing the pipe.
>
> In this case we don't mind that close fails.
>
> Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
Hmm, do you want a few helped-by lines here?
I'll queue this to 'pu', but only because I do not care too much about
this part of the codepath, not because I think this is explained well.
For example, what does "the reasons could be" mean? If the reasons turned
out to be totally different, that would make this patch useless? IOW, is
it fixing the real issue? Without knowing the reasons, how can we
conclude that "In this case" we don't mind?
Having said all that, I agree that you are seeing a failure exactly
because of the reason you stated above with an unnecessary weak "could
be". A filehandle to a pipe to cat-file is opened by the caller of
blob_mimetype(), it gets peeked at with -T inside the function, then it
gets peeked at with -B inside the caller (by the way, didn't anybody find
this sloppy? Why isn't blob_mimetype() doing all of that itself?), and
then after that the run_highligher closes the filehandle, because it does
not want to read from the unadorned cat-file output at all. Of course,
cat-file may receive SIGPIPE if we do that, and we know we don't care how
cat-file died in that particular case.
But do we care if the first cat-file died due to some other reason? Is
there anything that catches the failure mode?
> ---
> gitweb/gitweb.perl | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index ea984b9..eae75ac 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3465,8 +3465,7 @@ sub run_highlighter {
> my ($fd, $highlight, $syntax) = @_;
> return $fd unless ($highlight && defined $syntax);
>
> - close $fd
> - or die_error(404, "Reading blob failed");
> + close $fd;
> open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
> quote_command($highlight_bin).
> " --xhtml --fragment --syntax $syntax |"
> --
> 1.7.3.4.523.g72f0d.dirty
^ permalink raw reply
* jn/svn-fe (Re: What's cooking in git.git (Jan 2011, #01; Tue, 4))
From: Jonathan Nieder @ 2011-01-05 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Barr, Ramkumar Ramachandra
In-Reply-To: <7vipy4dy8y.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> * jn/svn-fe (2010-12-06) 18 commits
> - vcs-svn: Allow change nodes for root of tree (/)
> - vcs-svn: Implement Prop-delta handling
> - vcs-svn: Sharpen parsing of property lines
> - vcs-svn: Split off function for handling of individual properties
> - vcs-svn: Make source easier to read on small screens
> - vcs-svn: More dump format sanity checks
> - vcs-svn: Reject path nodes without Node-action
> - vcs-svn: Delay read of per-path properties
> - vcs-svn: Combine repo_replace and repo_modify functions
> - vcs-svn: Replace = Delete + Add
> - vcs-svn: handle_node: Handle deletion case early
> - vcs-svn: Use mark to indicate nodes with included text
> - vcs-svn: Unclutter handle_node by introducing have_props var
> - vcs-svn: Eliminate node_ctx.mark global
> - vcs-svn: Eliminate node_ctx.srcRev global
> - vcs-svn: Check for errors from open()
> - vcs-svn: Allow simple v3 dumps (no deltas yet)
> - vcs-svn: Error out for v3 dumps
>
> Some RFC patches, to give them early and wider exposure. Perhaps drop
> these during the -rc period?
The bottom one is a useful bugfix (to get an error message instead of
succeeding with nonsensical mode and blobs when the user tries to
import a --deltas dump) and should ideally be applied for v1.7.4.
The rest are a new feature (a surprisingly non-buggy one) and I don't
mind if you drop them.
^ permalink raw reply
* Re: [PATCH v2] t/t9001-send-email.sh: fix '&&' chain in some tests
From: Junio C Hamano @ 2011-01-04 23:56 UTC (permalink / raw)
To: Antonio Ospite; +Cc: git, Jonathan Nieder
In-Reply-To: <1294174618-14571-1-git-send-email-ospite@studenti.unina.it>
Thanks.
^ 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