* Re: git-1.4.0 make problems
From: Rene Scharfe @ 2006-06-17 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael Somos
In-Reply-To: <7vbqsra4d2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> I've been using (in my non-git related project aka day-job)
>
> git-tar-tree HEAD^{tree} $(PROJECT)-$(RELNAME) >$(PROJECT)-$(RELNAME).tar
>
> to avoid this. Although all of my target machines have gtar that are
> recent enough so I do not need it, but when the tarball has version
> string in its name, there is not much point having the pax header to
> identify the contents (where the pax header shines is when the result
> does not have the version string in its name).
>
> This might be a sensible thing to do for our dist target as well.
> The product of our dist target is for people who build from the
> source to bootstrap themselves (if they have git, then fetching the
> source using git is preferred anyway), as opposed to using pre-built
> binaries, so being as friendly as we can to different implementations
> of tar is a good thing.
Hrm. Is the header really that unfriendly? With a non-POSIX tar you
get an extra file and a nice, if somewhat cryptic, reminder to upgrade
your archiver. ;-) Seriously, this is way below my annoyance-radar,
but I'm obviously biased.
What do you think about the following patch for starters? It adds an
example to the git-tar-tree documentation showing your "tree trick"
and corrects two formatting buglets.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
index 831537b..c93a8fe 100644
--- a/Documentation/git-tar-tree.txt
+++ b/Documentation/git-tar-tree.txt
@@ -45,11 +45,16 @@ git tar-tree HEAD | (cd /var/tmp/ && mkd
latest commit on the current branch, and extracts it in
`/var/tmp/junk` directory.
-git tar-tree v2.6.17 linux-2.6.17 | gzip >linux-2.6.17.tar.gz
+git tar-tree v2.6.17 linux-2.6.17 | gzip >linux-2.6.17.tar.gz::
Create a tarball for v2.6.17 release.
-git tar-tree --remote=example.com:git.git v0.99 >git-0.99.tar
+git tar-tree v2.6.17{caret}\{tree\} linux-2.6.17 | gzip >linux-2.6.17.tar.gz::
+
+ Create a tarball for v2.6.17 release, but without a
+ global extended pax header.
+
+git tar-tree --remote=example.com:git.git v0.99 >git-0.99.tar::
Get a tarball v0.99 from example.com.
^ permalink raw reply related
* Post 1.4.0 merge status
From: Junio C Hamano @ 2006-06-17 21:38 UTC (permalink / raw)
To: git
I thank everybody who submitted patches while I was away.
I'm trying to catch up with you and have merged the following so
far to "master". Will push them out shortly after I review them
for the last time, hopefully sometime today:
- pulled git-svn updates from Eric Wong (I first applied the
patches from the list to a test branch, and compared it with
the result of the pull onto the master -- they match, so I
decided to take the pull result).
- pulled gitk from Paul to fix "Re-read references".
- git whatchanged to show full-history from Linus.
- Portability of t4101 test for diff implementations that do
not do "\No newline..." from Dennis Stosberg.
- mailinfo fix from Eric W Biederman not to confuse "From: "
lines in the middle of log message as an in-body header.
- gitweb 'blame' that can be switched on/off from Florian
Foster.
- gitweb README update from Jakub.
- git-blame updates to add -time from Fredrik.
- three patches to cvsimport from Martin.
- strlcpy from Peter Eriksen.
- a p4import update from Sean.
- cvsexportcommit typofix from Sven Verdoolaege.
I'll be looking at these after the above;
- 2 patches to diff (color and -b/w) from Johannes.
- avoiding "make prefix=A ; make prefix=B install" confusion
from Yakov.
I've queued the following to look at in the next round;
- format-patch -s fix from Eric W Biederman;
- 7+1 patches to make am and commands required for it built-in
from Lukas.
- raw-blob output from gitweb by Jakub.
- big "SHA1"->"SHA-1" and other documentation updates from
Horst; I was hoping to merge this while flying over Pacific,
but I seemed to have duplicates and was too tired and fell
asleep.
^ permalink raw reply
* Re: [PATCH for cvsps] Handle cvs repo with modules
From: Yann Dirson @ 2006-06-17 21:33 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git, cvsps
In-Reply-To: <200606151249.17518.lan@academsoft.ru>
On Thu, Jun 15, 2006 at 12:49:17PM +0700, Alexander Litvinov wrote:
> Parse 'Working file' lines from cvs log output. This alow to work
> with cvs repos with modules. To enable this you need to add
> --no-rlog to cvsps command line args. This patch was made to import
> such repo into git. But git-cvsimport can't load such data.
Just forgot to mention it, but this patch was applied to master.
Thanks,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [BUG] stgit branch renaming into new dir crashes
From: Yann Dirson @ 2006-06-17 21:31 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <b0943d9e0606160506g23179531v7921b67ac0e0aa0d@mail.gmail.com>
On Fri, Jun 16, 2006 at 01:06:56PM +0100, Catalin Marinas wrote:
> On 13/06/06, Yann Dirson <ydirson@altern.org> wrote:
> >When trying to rename a branch to a name including a slash, there is
> >no explicit creation of leading dirs, and stgit crashes:
> >
> >$ stg branch -r multitag dev/multitag
> >Traceback (most recent call last):
> [...]
>
> What version of StGIT are you using? It seems to be OK with 0.10.
Right, that was with 0.9, and works perfectly with 0.10. Relying too
much on /usr/bin/ ... :)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] cvsimport: ignore CVSPS_NO_BRANCH and impossible branches
From: Yann Dirson @ 2006-06-17 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In-Reply-To: <7vzmgb8plx.fsf@assigned-by-dhcp.cox.net>
On Sat, Jun 17, 2006 at 02:00:10PM -0700, Junio C Hamano wrote:
> Martin Langhoff <martin@catalyst.net.nz> writes:
>
> > cvsps output often contains references to CVSPS_NO_BRANCH, commits that it
> > could not trace to a branch. Ignore that branch.
> >
> > Additionally, cvsps will sometimes draw circular relationships between
> > branches -- where two branches are recorded as opening from the other.
> > In those cases, and where the ancestor branch hasn't been seen, ignore
> > it.
>
> This sounds more like an workaround than a real fix to me,
> although I'd apply it for now. I see Yann is collecting cvsps
> patches but maybe there will be a real fix soonish?
I have not dig yet into the cases that trigger CVSPS_NO_BRANCH so
can't make any promise, unless someone comes in with a patch already
written :)
Since the patch seems to ensure the user gets warned when a branch
gets ignored this way, allowing it in could probably allow at least
some people to have cvsimport does a partial job, rather than failing
midway. Maybe a final warning when all patchsets could not be
imported could be issued, so the existing ones do not get simply lost
in the verbose output.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] gitweb: safely output binary files for 'blob_plain' action
From: Junio C Hamano @ 2006-06-17 21:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git, Kay Sievers
In-Reply-To: <20060617153540.GI2609@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sat, Jun 17, 2006 at 01:32:15PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Introduced new configuration variables: $default_blob_plain_mimetype
>> and $default_text_plain_charset (only 'utf-8' is guaranteed to work
>> for the latter).
>
> Nah, defaulting to 'utf-8' is horrible - usually, you just don't have a
> clue and should refrain from sending any charset information at all, so
> I think undef is a much saner default.
Concurred. I see Jakub's second patch to make this
configurable, but I wonder about a few things:
- we might want to have a configuration mechanism in place
before enhancing gitweb. My gut feeling is that we can use
[gitweb] section in project.git/config (and probably
duplicate first and deprecate later existing "description" as
well).
- the blob charset should be per path -- otherwise the feature
would be not useful for projects that maintains bunch of po
files.
In other words, something like this:
(in torvalds/linux-2.6.git/config)
[gitweb]
description = "Linus's kernel tree"
; defaultblobcharset = "latin1"
blobmimemapfile = "mime-map"
(in torvalds/linux-2.6.git/mime-map, first match decides)
fs/nls/nls_euc-jp.c text/plain; charset=euc_jp
*.c text/plain; charset=utf-8
*.h text/plain; charset=utf-8
I do not think defaultblobcharset above is a good idea though.
You could just have the last entry in mime-map file to be:
* text/plain; charset=latin1
^ permalink raw reply
* Re: [PATCH] cvsimport: ignore CVSPS_NO_BRANCH and impossible branches
From: Junio C Hamano @ 2006-06-17 21:00 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, Yann Dirson
In-Reply-To: <11500135293734-git-send-email-martin@catalyst.net.nz>
Martin Langhoff <martin@catalyst.net.nz> writes:
> cvsps output often contains references to CVSPS_NO_BRANCH, commits that it
> could not trace to a branch. Ignore that branch.
>
> Additionally, cvsps will sometimes draw circular relationships between
> branches -- where two branches are recorded as opening from the other.
> In those cases, and where the ancestor branch hasn't been seen, ignore
> it.
This sounds more like an workaround than a real fix to me,
although I'd apply it for now. I see Yann is collecting cvsps
patches but maybe there will be a real fix soonish?
^ permalink raw reply
* Re: git-1.4.0 make problems
From: Junio C Hamano @ 2006-06-17 20:56 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git, Michael Somos
In-Reply-To: <4493A810.6010706@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> | 1) The untar process creates a stray file "pax_global_header".
> | I am using GNU tar v1.13.22 and I get this message :
> |
> | ======================================================================
> | > tar jxf ~/u/source/git-1.4.0.tar.bz2
> | tar: pax_global_header: Unknown file type 'g', extracted as normal
> | file
> | ======================================================================
>
> You can ignore or delete that file. It is a pax extended global header,
> containing the git commit ID as a comment. GNU tar started supporting
> pax headers with version 1.13.93 (released 2004-02-23). Version 1.13.22
> was released on 2001-08-29, by the way. May I ask what operating system
> and version you are using?
I've been using (in my non-git related project aka day-job)
git-tar-tree HEAD^{tree} $(PROJECT)-$(RELNAME) >$(PROJECT)-$(RELNAME).tar
to avoid this. Although all of my target machines have gtar
that are recent enough so I do not need it, but when the tarball
has version string in its name, there is not much point having
the pax header to identify the contents (where the pax header
shines is when the result does not have the version string in
its name).
This might be a sensible thing to do for our dist target as
well. The product of our dist target is for people who build
from the source to bootstrap themselves (if they have git, then
fetching the source using git is preferred anyway), as opposed
to using pre-built binaries, so being as friendly as we can to
different implementations of tar is a good thing.
^ permalink raw reply
* Re: [PATCH] Update gitweb README: gitweb is now included with git
From: Junio C Hamano @ 2006-06-17 20:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e708tr$ea8$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> ---
> ftp://ftp.kernel.org/pub/software/scm/gitweb/ and
> http://www.kernel.org/pub/software/scm/gitweb/ are empty.
>
> http://www.kernel.org/git/?p=git/gitweb.git;a=summary
> does not exist.
Thanks.
^ permalink raw reply
* Re: Shrink "struct object" a bit
From: Linus Torvalds @ 2006-06-17 19:13 UTC (permalink / raw)
To: Philip Pokorny; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <44942176.1070107@mindspring.com>
On Sat, 17 Jun 2006, Philip Pokorny wrote:
>
> A minor thing, but doesn't this mean the "report_missing" message would change
> from:
>
> > Cannot obtain needed object ab12cdef1234567890abcd
> > while processing commit fedcbadeadbeefdeadbe
>
> to
>
> > Cannot obtain needed none ab12cdef1234567890abcd
> > while processing commit fedcbadeadbeefdeadbe
Yeah. I guess you could either just keep the old conditional, or just
change the object type-name for the unspecified mode 0 to something like
"untyped object" which would cause a much more readable errors.
Linus
^ permalink raw reply
* Re: [PATCH] CVSps fixed; git-cvsimport works, too
From: Yann Dirson @ 2006-06-17 18:51 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: GIT list, cvsps
In-Reply-To: <20060617143443.GA29602@pe.Belkin>
On Sat, Jun 17, 2006 at 10:34:43AM -0400, Chris Shoemaker wrote:
> Are you saying there was no pre-existing cache file when the patched
> version was first run?
It was the sample script you provided to demonstrate the problem which
showed the new issue: it does a "cvsps -x" first, then runs
git-cvsimport, which runs "cvsps -u". That one does fails. I'm
pretty sure the cache does not exist beforehand, since your script
creates the repo in a temporary directory.
BTW, I'll see about adding a testsuite to cvsps, based on the
framework used by git. All these scriptlets used to exhibit the
various problems have to be kept somewhere.
> Did you delete it? If so, then there's a bug somewhere.
I do think there is a bug somewhere :)
> The complaint is basically, Hey, there's an initial branch
> determination already made for this file, but it's not the one I would
> have made, so it must have been restored from a cache file that I
> didn't make.
OK, thanks for the clarification.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* [PATCH] git-cvsexportcommit.perl: fix typo
From: Sven Verdoolaege @ 2006-06-17 17:46 UTC (permalink / raw)
To: Yann Dirson; +Cc: junkio, git
In-Reply-To: <20060527163935.474.22794.stgit@gandelf.nowhere.earth>
---
git-cvsexportcommit.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 57088c3..d1051d0 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -134,7 +134,7 @@ foreach my $f (@afiles) {
and $status[0] !~ m/^File: no file /) {
$dirty = 1;
warn "File $f is already known in your CVS checkout -- perhaps it has been added by another user. Or this may indicate that it exists on a different branch. If this is the case, use -f to force the merge.\n";
- warn "Status was: $status\n";
+ warn "Status was: $status[0]\n";
}
}
foreach my $f (@mfiles, @dfiles) {
--
1.4.0-dirty
^ permalink raw reply related
* Re: parsecvs and unnamed branches
From: Keith Packard @ 2006-06-17 17:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, Pavel Roskin, git
In-Reply-To: <9e4733910606162251i65021336m4388d4da715befc9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 510 bytes --]
On Sat, 2006-06-17 at 01:51 -0400, Jon Smirl wrote:
> Have you checked parsecvs on the 38 test repositories in the cvs2svn source?
Those all run to completion without significant error (there are a
couple of tests with invalid symbol names that currently elicit errors).
I haven't validated that the imports are correct though; spot checks
seem to indicate that the problems encountered during the cvs2svn
development aren't the same as the problems we're finding.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] gitweb: text files for 'blob_plain' action without charset by default
From: Jakub Narebski @ 2006-06-17 16:07 UTC (permalink / raw)
To: git
In-Reply-To: <20060617153540.GI2609@pasky.or.cz>
$default_text_plain_charset is undefined (no specified charset) by
default. Additionally ':raw' layer for binmode is used for outputting file
content.
---
This patch depends on the previous patch in the thread:
"gitweb: safely output binary files for 'blob_plain' action"
Contrary to the previous patch it is not based on other unrelated gitweb.cgi
patches (this changes only line numbers in patch).
gitweb/gitweb.cgi | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
53209981db06a5dde7c59caada279bf63d329da8
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index acac1f4..f082e5d 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -44,7 +44,7 @@ my $projects_list = "index/index.aux";
# default blob_plain mimetype and default charset for text/plain blob
my $default_blob_plain_mimetype = 'text/plain';
-my $default_text_plain_charset = 'utf-8'; # can be undefined
+my $default_text_plain_charset = undef; # was: 'utf-8'
# input validation and dispatch
my $action = $cgi->param('a');
@@ -1451,9 +1451,9 @@ sub git_blob_plain {
print $cgi->header(-type => "$type", '-content-disposition' => "inline; filename=\"$save_as\"");
undef $/;
- binmode STDOUT, ':raw' unless $type =~ m/^text\//;
+ binmode STDOUT, ':raw';
print <$fd>;
- binmode STDOUT, ':utf8' unless $type =~ m/^text\//;
+ binmode STDOUT, ':utf8'; # as set at the beginning of gitweb.cgi
$/ = "\n";
close $fd;
}
--
1.3.0
^ permalink raw reply related
* Re: Shrink "struct object" a bit
From: Philip Pokorny @ 2006-06-17 15:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606141630570.5498@g5.osdl.org>
Linus Torvalds wrote:
>This shrinks "struct object" by a small amount, by getting rid of the
>"struct type *" pointer and replacing it with a 3-bit bitfield instead.
>
>@@ -179,9 +179,7 @@ static int loop(void)
> */
> if (! (obj->flags & TO_SCAN)) {
> if (fetch(obj->sha1)) {
>- report_missing(obj->type
>- ? obj->type
>- : "object", obj->sha1);
>+ report_missing(typename(obj->type), obj->sha1);
> return -1;
> }
> }
>
>
>diff --git a/object.c b/object.c
>index 9adc874..0f70890 100644
>--- a/object.c
>+++ b/object.c
>@@ -9,6 +9,10 @@ struct object **objs;
> static int nr_objs;
> int obj_allocs;
>
>+const char *type_names[] = {
>+ "none", "blob", "tree", "commit", "bad"
>+};
>+
>
>
A minor thing, but doesn't this mean the "report_missing" message would
change from:
> Cannot obtain needed object ab12cdef1234567890abcd
> while processing commit fedcbadeadbeefdeadbe
to
> Cannot obtain needed none ab12cdef1234567890abcd
> while processing commit fedcbadeadbeefdeadbe
in some cases? I'm not sure that it's possible for the type value to be
unspecified at this point in the code, but it seemed like the output
from report_missing would be confusing if this ever happened.
:v)
^ permalink raw reply
* Re: [PATCH] gitweb: safely output binary files for 'blob_plain' action
From: Petr Baudis @ 2006-06-17 15:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Kay Sievers, Junio C Hamano
In-Reply-To: <200606171332.15591.jnareb@gmail.com>
Dear diary, on Sat, Jun 17, 2006 at 01:32:15PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Introduced new configuration variables: $default_blob_plain_mimetype
> and $default_text_plain_charset (only 'utf-8' is guaranteed to work
> for the latter).
Nah, defaulting to 'utf-8' is horrible - usually, you just don't have a
clue and should refrain from sending any charset information at all, so
I think undef is a much saner default.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* [PATCH] Make t4101-apply-nonl bring along its patches
From: Dennis Stosberg @ 2006-06-17 15:02 UTC (permalink / raw)
To: Michael Somos; +Cc: git, rene.scharfe
In-Reply-To: <200606171446.k5HEkZAx006686@grail.cba.csuohio.edu>
Some versions of "diff" (e.g. on FreeBSD and older Linux systems) do
not support the "\ No newline at end of file" remark and are not
able to generate the patches needed for this test. This lets the
test fail, although git-apply is working perfectly. This patch adds
the pre-generated patches to t/t4100/ and makes the test use them.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
t/t4101-apply-nonl.sh | 6 +-----
t/t4101/diff.0-1 | 6 ++++++
t/t4101/diff.0-2 | 7 +++++++
t/t4101/diff.0-3 | 8 ++++++++
t/t4101/diff.1-0 | 6 ++++++
t/t4101/diff.1-2 | 8 ++++++++
t/t4101/diff.1-3 | 8 ++++++++
t/t4101/diff.2-0 | 7 +++++++
t/t4101/diff.2-1 | 8 ++++++++
t/t4101/diff.2-3 | 7 +++++++
t/t4101/diff.3-0 | 8 ++++++++
t/t4101/diff.3-1 | 8 ++++++++
t/t4101/diff.3-2 | 7 +++++++
13 files changed, 89 insertions(+), 5 deletions(-)
diff --git a/t/t4101-apply-nonl.sh b/t/t4101-apply-nonl.sh
index 26b131d..026fac8 100755
--- a/t/t4101-apply-nonl.sh
+++ b/t/t4101-apply-nonl.sh
@@ -20,14 +20,10 @@ do
for j in 0 1 2 3
do
test $i -eq $j && continue
- diff -u frotz.$i frotz.$j |
- sed -e '
- /^---/s|.*|--- a/frotz|
- /^+++/s|.*|+++ b/frotz|' >diff.$i-$j
cat frotz.$i >frotz
test_expect_success \
"apply diff between $i and $j" \
- "git-apply <diff.$i-$j && diff frotz.$j frotz"
+ "git-apply <../t4101/diff.$i-$j && diff frotz.$j frotz"
done
done
diff --git a/t/t4101/diff.0-1 b/t/t4101/diff.0-1
new file mode 100644
index 0000000..1010a88
--- /dev/null
+++ b/t/t4101/diff.0-1
@@ -0,0 +1,6 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,3 @@
+ a
+ b
++c
diff --git a/t/t4101/diff.0-2 b/t/t4101/diff.0-2
new file mode 100644
index 0000000..36460a2
--- /dev/null
+++ b/t/t4101/diff.0-2
@@ -0,0 +1,7 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,2 @@
+ a
+-b
++b
+\ No newline at end of file
diff --git a/t/t4101/diff.0-3 b/t/t4101/diff.0-3
new file mode 100644
index 0000000..b281c43
--- /dev/null
+++ b/t/t4101/diff.0-3
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,3 @@
+ a
+-b
++c
++b
+\ No newline at end of file
diff --git a/t/t4101/diff.1-0 b/t/t4101/diff.1-0
new file mode 100644
index 0000000..f0a2e92
--- /dev/null
+++ b/t/t4101/diff.1-0
@@ -0,0 +1,6 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,2 @@
+ a
+ b
+-c
diff --git a/t/t4101/diff.1-2 b/t/t4101/diff.1-2
new file mode 100644
index 0000000..2a440a5
--- /dev/null
+++ b/t/t4101/diff.1-2
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,2 @@
+ a
+-b
+-c
++b
+\ No newline at end of file
diff --git a/t/t4101/diff.1-3 b/t/t4101/diff.1-3
new file mode 100644
index 0000000..61aff97
--- /dev/null
+++ b/t/t4101/diff.1-3
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,3 @@
+ a
+-b
+ c
++b
+\ No newline at end of file
diff --git a/t/t4101/diff.2-0 b/t/t4101/diff.2-0
new file mode 100644
index 0000000..c2e71ee
--- /dev/null
+++ b/t/t4101/diff.2-0
@@ -0,0 +1,7 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,2 @@
+ a
+-b
+\ No newline at end of file
++b
diff --git a/t/t4101/diff.2-1 b/t/t4101/diff.2-1
new file mode 100644
index 0000000..a66d9fd
--- /dev/null
+++ b/t/t4101/diff.2-1
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,3 @@
+ a
+-b
+\ No newline at end of file
++b
++c
diff --git a/t/t4101/diff.2-3 b/t/t4101/diff.2-3
new file mode 100644
index 0000000..5633c83
--- /dev/null
+++ b/t/t4101/diff.2-3
@@ -0,0 +1,7 @@
+--- a/frotz
++++ b/frotz
+@@ -1,2 +1,3 @@
+ a
++c
+ b
+\ No newline at end of file
diff --git a/t/t4101/diff.3-0 b/t/t4101/diff.3-0
new file mode 100644
index 0000000..10b1a41
--- /dev/null
+++ b/t/t4101/diff.3-0
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,2 @@
+ a
+-c
+-b
+\ No newline at end of file
++b
diff --git a/t/t4101/diff.3-1 b/t/t4101/diff.3-1
new file mode 100644
index 0000000..c799c60
--- /dev/null
+++ b/t/t4101/diff.3-1
@@ -0,0 +1,8 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,3 @@
+ a
++b
+ c
+-b
+\ No newline at end of file
diff --git a/t/t4101/diff.3-2 b/t/t4101/diff.3-2
new file mode 100644
index 0000000..f8d1ba6
--- /dev/null
+++ b/t/t4101/diff.3-2
@@ -0,0 +1,7 @@
+--- a/frotz
++++ b/frotz
+@@ -1,3 +1,2 @@
+ a
+-c
+ b
+\ No newline at end of file
--
1.4.0
^ permalink raw reply related
* Re: git-1.4.0 make problems
From: Michael Somos @ 2006-06-17 14:46 UTC (permalink / raw)
To: dennis; +Cc: git, rene.scharfe
Dennis Stosberg wrote :
> I have seen this test failing on FreeBSD 5.3, too. FreeBSD comes with a
> version of "diff" which does not add the "\ No newline at end of file"
> remark. Maybe your "diff" is simply too old. In that case, it's not a
> serious problem because Git uses its own internal diff implementation.
You are exactly right. My "diff" is a bit too old. It was 2.7 and the
latest stable is 2.8.1 which fixes the newline problem.
> The intention of this test is to test git-apply and not the system's
> "diff", so perhaps it should bring along all its patches and not rely
> on the system's "diff" to generate them...
That seems like a good suggestion if it is as you wrote. Thanks for the
information regarding diff and git. Shalom, Michael
^ permalink raw reply
* Re: [PATCH] CVSps fixed; git-cvsimport works, too
From: Chris Shoemaker @ 2006-06-17 14:34 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list, cvsps
In-Reply-To: <20060617134717.GR7766@nowhere.earth>
On Sat, Jun 17, 2006 at 03:47:17PM +0200, Yann Dirson wrote:
> On Sat, Jun 17, 2006 at 09:20:23AM -0400, Chris Shoemaker wrote:
> > >
> > > * when run with "-A" cvsps notices the inconsistency:
> > >
> > > invalid initial_branch for file a, probably from old cache, run with -x.
> >
> > good advice.
> >
> > >
> > >
> > > I have included the current version of your patch in branch "to-check"
> > > in http://ydirson.free.fr/soft/git/cvsps.git/. I did not tak time to
> > > look at it closely yet - do you plan to work on this issue ?
> >
> > I wondered if you'd find that. Evidentally, you're being thorough. :)
> >
> > The intent of my patch is only to affect the branch ancestry
> > calculation. IIRC, the patch version is incompatible with cached
> > results from unpatched versions. Hence I would only expect it to work
> > with '-x -A' (unless there was no pre-existing cache file).
>
> All those tests were done with your patch applied, so the cache was
> generated and re-read using the pached version.
Are you saying there was no pre-existing cache file when the patched
version was first run? Did you delete it? If so, then there's a bug
somewhere.
>
> > There's probably some nicer way to handle the cache incompatibility,
> > but my current approach has been to tell people to delete their old
> > cache file or run wih -x. Suggestions are welcome.
>
> If the cache format is changed, this would be a good candidate for the
> "v2" cache format. I already have 2 (incomplete) patches that well
> need to bump the cache format version - see branches multitag (allow
> several tags per patchset) and semicolon (allow semicolons in
> filenames).
IIRC, it's not syntactically incompatible - it's just that the patched
version can tell that it doesn't trust the initial branch
determinations that are stored in the cache file by an unpatched
version.
The complaint is basically, Hey, there's an initial branch
determination already made for this file, but it's not the one I would
have made, so it must have been restored from a cache file that I
didn't make.
-chris
>
> Best regards,
> --
> Yann Dirson <ydirson@altern.org> |
> Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
> | Freedom, Power, Stability, Gratis
> http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] CVSps fixed; git-cvsimport works, too
From: Yann Dirson @ 2006-06-17 13:47 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: GIT list, cvsps
In-Reply-To: <20060617132023.GA29452@pe.Belkin>
On Sat, Jun 17, 2006 at 09:20:23AM -0400, Chris Shoemaker wrote:
> >
> > * when run with "-A" cvsps notices the inconsistency:
> >
> > invalid initial_branch for file a, probably from old cache, run with -x.
>
> good advice.
>
> >
> >
> > I have included the current version of your patch in branch "to-check"
> > in http://ydirson.free.fr/soft/git/cvsps.git/. I did not tak time to
> > look at it closely yet - do you plan to work on this issue ?
>
> I wondered if you'd find that. Evidentally, you're being thorough. :)
>
> The intent of my patch is only to affect the branch ancestry
> calculation. IIRC, the patch version is incompatible with cached
> results from unpatched versions. Hence I would only expect it to work
> with '-x -A' (unless there was no pre-existing cache file).
All those tests were done with your patch applied, so the cache was
generated and re-read using the pached version.
> There's probably some nicer way to handle the cache incompatibility,
> but my current approach has been to tell people to delete their old
> cache file or run wih -x. Suggestions are welcome.
If the cache format is changed, this would be a good candidate for the
"v2" cache format. I already have 2 (incomplete) patches that well
need to bump the cache format version - see branches multitag (allow
several tags per patchset) and semicolon (allow semicolons in
filenames).
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] CVSps fixed; git-cvsimport works, too
From: Chris Shoemaker @ 2006-06-17 13:20 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list, cvsps
In-Reply-To: <20060617122158.GQ7766@nowhere.earth>
On Sat, Jun 17, 2006 at 02:21:58PM +0200, Yann Dirson wrote:
> [for original thread see
> http://www.gelato.unsw.edu.au/archives/git/0511/11812.html]
>
> Hi Chris,
>
> I was looking at your patch and test script to decide whether to
> include it in my cvsps patch collection, but it seems there are still
> problems:
>
> * when run with "-x" it gives the expected result, even with "-A"
This is expected.
>
> * when run without "-x" and without "-A", the patchset introducing
> file "b" and branch "stable" does not appear, without even a warning
With out "-A" I don't think the patch is operative.
>
> * when run with "-A" cvsps notices the inconsistency:
>
> invalid initial_branch for file a, probably from old cache, run with -x.
good advice.
>
>
> I have included the current version of your patch in branch "to-check"
> in http://ydirson.free.fr/soft/git/cvsps.git/. I did not tak time to
> look at it closely yet - do you plan to work on this issue ?
I wondered if you'd find that. Evidentally, you're being thorough. :)
The intent of my patch is only to affect the branch ancestry
calculation. IIRC, the patch version is incompatible with cached
results from unpatched versions. Hence I would only expect it to work
with '-x -A' (unless there was no pre-existing cache file).
I've had one independent report of success from someone who found and
used my patch.
I haven't had to use cvsps recently, so I don't know how much time
I'll have for cvsps hacking, but I'm interested in getting feedback on
my current patch.
There's probably some nicer way to handle the cache incompatibility,
but my current approach has been to tell people to delete their old
cache file or run wih -x. Suggestions are welcome.
-chris
^ permalink raw reply
* Re: git-1.4.0 make problems
From: Dennis Stosberg @ 2006-06-17 13:09 UTC (permalink / raw)
To: Michael Somos; +Cc: rene.scharfe, git
In-Reply-To: <200606171016.k5HAGQ1D005560@grail.cba.csuohio.edu>
Michael Somos wrote:
> A good suggestion, but I am a newbie as you can tell, and would prefer to
> play in a sandbox for some time before I would attempt it. Of more concern
> to me now is a failed test :
>
> > * FAIL 12: apply diff between 3 and 2
> > git-apply <diff.3-2 && diff frotz.2 frotz
> > * failed 2 among 12 test(s)
> > make[1]: *** [t4101-apply-nonl.sh] Error 1
I have seen this test failing on FreeBSD 5.3, too. FreeBSD comes with a
version of "diff" which does not add the "\ No newline at end of file"
remark. Maybe your "diff" is simply too old. In that case, it's not a
serious problem because Git uses its own internal diff implementation.
The intention of this test is to test git-apply and not the system's
"diff", so perhaps it should bring along all its patches and not rely
on the system's "diff" to generate them...
Regards,
Dennis
^ permalink raw reply
* Re: [PATCH] CVSps fixed; git-cvsimport works, too
From: Yann Dirson @ 2006-06-17 12:21 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: GIT list, cvsps
[for original thread see
http://www.gelato.unsw.edu.au/archives/git/0511/11812.html]
Hi Chris,
I was looking at your patch and test script to decide whether to
include it in my cvsps patch collection, but it seems there are still
problems:
* when run with "-x" it gives the expected result, even with "-A"
* when run without "-x" and without "-A", the patchset introducing
file "b" and branch "stable" does not appear, without even a warning
* when run with "-A" cvsps notices the inconsistency:
invalid initial_branch for file a, probably from old cache, run with -x.
I have included the current version of your patch in branch "to-check"
in http://ydirson.free.fr/soft/git/cvsps.git/. I did not tak time to
look at it closely yet - do you plan to work on this issue ?
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* [PATCH] gitweb: safely output binary files for 'blob_plain' action
From: Jakub Narebski @ 2006-06-17 11:32 UTC (permalink / raw)
To: git; +Cc: Kay Sievers, Junio C Hamano
gitweb tries now to output correct Content-Type header for
'blob_plain' action; for now text/plain for text files,
appropriate image MIME type for *.png, *.gif and *.jpg/*.jpeg files,
and application/octet-stream for other binary files.
Introduced new configuration variables: $default_blob_plain_mimetype
and $default_text_plain_charset (only 'utf-8' is guaranteed to work
for the latter).
binmode changed to ':raw' in git_blob_plain for output of non-text files.
---
gitweb/gitweb.cgi | 43 +++++++++++++++++++++++++++++++++++++++----
1 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 9d902b7..b37ec50 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -39,12 +39,16 @@ # html text to include at home page
my $home_text = "indextext.html";
# URI of default stylesheet
-my $stylesheet = "gitweb.css";
+my $stylesheet = "gitweb.css";
# source of projects list
#my $projects_list = $projectroot;
my $projects_list = "index/index.aux";
+# default blob_plain mimetype and default charset for text/plain blob
+my $default_blob_plain_mimetype = 'text/plain';
+my $default_text_plain_charset = 'utf-8'; # can be undefined
+
# input validation and dispatch
my $action = $cgi->param('a');
if (defined $action) {
@@ -1354,15 +1358,46 @@ sub git_blob {
git_footer_html();
}
+sub git_blob_plain_mimetype {
+ my $fd = shift;
+ my $filename = shift;
+
+ # just in case
+ return $default_blob_plain_mimetype unless $fd;
+
+ if (-T $fd) {
+ return 'text/plain' .
+ ($default_text_plain_charset ? '; charset='.$default_text_plain_charset : '');
+ } elsif (! $filename) {
+ return 'application/octet-stream';
+ } elsif ($filename =~ m/\.png$/i) {
+ return 'image/png';
+ } elsif ($filename =~ m/\.gif$/i) {
+ return 'image/gif';
+ } elsif ($filename =~ m/\.jpe?g$/i) {
+ return 'image/jpeg';
+ } else {
+ return 'application/octet-stream';
+ }
+}
+
sub git_blob_plain {
- my $save_as = "$hash.txt";
+ open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or return;
+ my $type = git_blob_plain_mimetype($fd, $file_name);
+
+ # save as filename, even when no $file_name is given
+ my $save_as = "$hash";
if (defined $file_name) {
$save_as = $file_name;
+ } elsif ($type =~ m/^text\//) {
+ $save_as .= '.txt';
}
- print $cgi->header(-type => "text/plain", -charset => 'utf-8', '-content-disposition' => "inline; filename=\"$save_as\"");
- open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or return;
+
+ print $cgi->header(-type => "$type", '-content-disposition' => "inline; filename=\"$save_as\"");
undef $/;
+ binmode STDOUT, ':raw' unless $type =~ m/^text\//;
print <$fd>;
+ binmode STDOUT, ':utf8' unless $type =~ m/^text\//;
$/ = "\n";
close $fd;
}
--
1.3.0
^ permalink raw reply related
* Re: git-1.4.0 make problems
From: Michael Somos @ 2006-06-17 10:16 UTC (permalink / raw)
To: rene.scharfe; +Cc: git
Rene Scharfe wrote :
> | tar: pax_global_header: Unknown file type 'g', extracted as normal
> You can ignore or delete that file. It is a pax extended global header,
Yes, I knew I could ignore the file right away. I figured it was due
to some new feature of GNU tar.
> was released on 2001-08-29, by the way. May I ask what operating system
> and version you are using?
Mandrake 8,1 for i586. I had not encountered problems with GNU tar 1.13.22
before. A quick google showed this was not a rare problem, but nothing in
the tarball for git-1.4.0 mentioned this problem. I understand that it may
be a rare or nonexistant problem for the target audience of "git", but just
a sentence or two would be enough clue to help out those who may need it.
> It took me a while to realize that your diffs are reversed. It's too
Yes, unfortunately, I did reverse it, but even patch can handle that.
> A good first exercise would be to fetch the git repository, edit Makefile
> and commit your change, and then send a patch to this list -- all using
A good suggestion, but I am a newbie as you can tell, and would prefer to
play in a sandbox for some time before I would attempt it. Of more concern
to me now is a failed test :
> * FAIL 12: apply diff between 3 and 2
> git-apply <diff.3-2 && diff frotz.2 frotz
> * failed 2 among 12 test(s)
> make[1]: *** [t4101-apply-nonl.sh] Error 1
All the other tests worked which is great. Thanks for your reply. Shalom,
Michael
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox