* [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: [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
* 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
* [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: 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] 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: [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
* 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] 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: 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] 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: [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: 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: [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 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
* 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: 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
* Re: [PATCH] gitweb: safely output binary files for 'blob_plain' action
From: Petr Baudis @ 2006-06-17 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Kay Sievers
In-Reply-To: <7v8xnv8ozp.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jun 17, 2006 at 11:13:30PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> - 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).
Agreed. (I planned to back this up with a patch, then looked at the
clock.)
Hmm, after I'm over my exam period, since there's now another .pl thing
in the git tree I might start working on some kind of universal Git.pm
interface. I'm gonna need it for Cogito in the longer term anyway. ;-)
> - 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
You could as well just support the mime.types format and load
/etc/mime.types for this kind of mapping (see below for a patch). The
advantage is that this pretty much covers all the MIME types you will
need, the disadvantage is that it's less flexible and the charset part
wouldn't probably fit in nicely.
We could obviously do both. :-)
---
[PATCH] Support for the standard mime.types map in gitweb
gitweb will try to look up the filename mimetype in /etc/mime.types
and optionally a user-configured mime.types map as well.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Depends on Jakub's mime patches.
gitweb/gitweb.cgi | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 9250548..0116531 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -46,6 +46,11 @@ # default blob_plain mimetype and defaul
my $default_blob_plain_mimetype = 'text/plain';
my $default_text_plain_charset = undef; # was: 'utf-8'
+# file to use for guessing MIME types before trying /etc/mime.types
+# (relative to the current git repository)
+my $mimetypes_file = undef;
+
+
# input validation and dispatch
my $action = $cgi->param('a');
if (defined $action) {
@@ -1414,6 +1419,40 @@ sub git_blob {
git_footer_html();
}
+sub mimetype_guess_file {
+ my $filename = shift;
+ my $mimemap = shift;
+ -r $mimemap or return undef;
+
+ my %mimemap;
+ open(MIME, $mimemap) or return undef;
+ while (<MIME>) {
+ my ($mime, $exts) = split(/\t+/);
+ my @exts = split(/\s+/, $exts);
+ foreach my $ext (@exts) {
+ $mimemap{$ext} = $mime;
+ }
+ }
+ close(MIME);
+
+ $filename =~ /\.(.*?)$/;
+ return $mimemap{$1};
+}
+
+sub mimetype_guess {
+ my $filename = shift;
+ my $mime;
+ $filename =~ /\./ or return undef;
+
+ if ($mimetypes_file) {
+ my $file = $mimetypes_file;
+ $file =~ m#^/# or $file = "$projectroot/$path/$file";
+ $mime = mimetype_guess_file($filename, $file);
+ }
+ $mime ||= mimetype_guess_file($filename, '/etc/mime.types');
+ return $mime;
+}
+
sub git_blob_plain_mimetype {
my $fd = shift;
my $filename = shift;
@@ -1421,6 +1460,11 @@ sub git_blob_plain_mimetype {
# just in case
return $default_blob_plain_mimetype unless $fd;
+ if ($filename) {
+ my $mime = mimetype_guess($filename);
+ $mime and return $mime;
+ }
+
if (-T $fd) {
return 'text/plain' .
($default_text_plain_charset ? '; charset='.$default_text_plain_charset : '');
--
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 related
* Re: git-1.4.0 make problems
From: Rene Scharfe @ 2006-06-17 22:11 UTC (permalink / raw)
To: Michael Somos; +Cc: Git Mailing List
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.
You already sent a diff in your first message, so you're not that much
of a newbie. :-)
Thanks for telling us about your first encounter with git, by the way.
Take your time, and have fun learning and using git!
René
^ permalink raw reply
* Re: [PATCH] gitweb: safely output binary files for 'blob_plain' action
From: Junio C Hamano @ 2006-06-17 22:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git, Kay Sievers
In-Reply-To: <20060617220106.GJ2609@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> 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
>
> You could as well just support the mime.types format and load
> /etc/mime.types for this kind of mapping (see below for a patch). The
> advantage is that this pretty much covers all the MIME types you will
> need, the disadvantage is that it's less flexible and the charset part
> wouldn't probably fit in nicely.
Ah, I thought Jakub's patch was already taking care of
mime.types but apparently that was not the case. As you say,
using /etc/mime.types for this is obviously a good point to
start.
> We could obviously do both. :-)
The point of my example was about charset part; comparing the
suffix part only is not good enough for .po files, so we should
obviously do both.
^ permalink raw reply
* Re: git-1.4.0 make problems
From: Junio C Hamano @ 2006-06-17 22:40 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <44947A43.7070909@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> 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.
I do not mind tar-tree producing the header by default and
having to override it with ^{tree} -- actually I think it is a
good default. I think that particular use in our Makefile,
however, is not necessary.
> What do you think about the following patch for starters?
Documentation updates are always welcome, and I think this is a
good change. Thanks.
^ permalink raw reply
* [RFD] gitweb configuration
From: Jakub Narebski @ 2006-06-17 22:48 UTC (permalink / raw)
To: git
Petr Baudis <pasky@suse.cz> writes:
> - 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 problem is we have different types of configuration in gitweb, and we
should take care where to put appropriate configuration options/variables.
- build time options, like $gitexecdir ($gitbin now) or $gitweb_version
($version now) which could be set at build time a la ./configure i.e
my $gitexecdir = "@GIT_EXEC_DIR@"; or something like that.
- gitweb installation options (gitweb version need not to correspond to
git version, and we could theoretically have more than one gitweb
installation while one git-core installation). It was proposed to put
such options on gitweb.conf file in the same directory as gitweb.cgi.
Unfortunately if one would want to use git-repo-config for managing
gitweb.conf one is out of luck: git-repo-config uses $GIT_DIR/config.
Among installation options we could put also defaults for repository-wide
(repository specific) options.
Global gitweb options include:
* $projectroot - absolute fs-path which will be prepended to the
project path, i.e. where projects to display are located (dir)
* $projects_list - source of projects list (file)
* $home_text - html text to include at home page (file)
* $stylesheet - default gitweb stylesheet (file)
* $git_temp - where to place temporary files (dir)
- repository specific options, of which gitweb for now uses only
$GIT_DIR/description, and which could use repository configuration,
[gitweb] section.
Repository specific options [can] include:
* description - One line description of repository;
theoretical problem: HTML escaping.
* blame - to make 'blame'/'annotate' interface available.
* blobmimemapfile - for repository specific mime map for blob_plain.
* favicon - if default favicon is not used.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] cg-admin-rewritehist: catch git-rev-list returning no commit
From: Petr Baudis @ 2006-06-17 23:21 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20060611120455.12116.14042.stgit@gandelf.nowhere.earth>
Dear diary, on Sun, Jun 11, 2006 at 02:04:55PM CEST, I got a letter
where Yann Dirson <ydirson@altern.org> said that...
> Signed-off-by: Yann Dirson <ydirson@altern.org>
> ---
>
> cg-admin-rewritehist | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
> index 861c7f6..fe3f210 100755
> --- a/cg-admin-rewritehist
> +++ b/cg-admin-rewritehist
> @@ -199,6 +199,10 @@ done
> git-rev-list --topo-order HEAD $startrev | tac >../revs
> commits=$(cat ../revs | wc -l)
>
> +if [ $commits -eq 0 ]; then
> + die "Found nothing to rewrite"
> +fi
> +
> i=0
> while read commit; do
> i=$((i+1))
Thanks, applied.
Dear diary, on Sun, Jun 11, 2006 at 02:04:57PM CEST, I got a letter
where Yann Dirson <ydirson@altern.org> said that...
> Signed-off-by: Yann Dirson <ydirson@altern.org>
> ---
>
> cg-admin-rewritehist | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
> index fe3f210..7cbdb30 100755
> --- a/cg-admin-rewritehist
> +++ b/cg-admin-rewritehist
> @@ -154,6 +154,8 @@ while optparse; do
> if optparse -d=; then
> tempdir="$OPTARG"
> elif optparse -r=; then
> + git-rev-parse "$OPTARG" >/dev/null || die "Unknown revision '$OPTARG'"
> + git-rev-parse "$OPTARG^" >/dev/null || die "Revision '$OPTARG' does not have parents, check what you really want"
> startrev="^$OPTARG^ $OPTARG $startrev"
> startrevparents="$OPTARG $startrevparents"
> elif optparse --env-filter=; then
Thanks, I've adapted it to the current codebase.
Dear diary, on Sun, Jun 11, 2006 at 02:05:00PM CEST, I got a letter
where Yann Dirson <ydirson@altern.org> said that...
> This is a fix for 95621e54cedef1c4a270af5570a72fc1331b5fcb.
>
> Signed-off-by: Yann Dirson <ydirson@altern.org>
> ---
>
> cg-admin-rewritehist | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
> index 7cbdb30..6dd8b92 100755
> --- a/cg-admin-rewritehist
> +++ b/cg-admin-rewritehist
> @@ -157,7 +157,7 @@ while optparse; do
> git-rev-parse "$OPTARG" >/dev/null || die "Unknown revision '$OPTARG'"
> git-rev-parse "$OPTARG^" >/dev/null || die "Revision '$OPTARG' does not have parents, check what you really want"
> startrev="^$OPTARG^ $OPTARG $startrev"
> - startrevparents="$OPTARG $startrevparents"
> + startrevparents="$OPTARG^ $startrevparents"
> elif optparse --env-filter=; then
> filter_env="$OPTARG"
> elif optparse --tree-filter=; then
Thanks; I've already applied a patch similar in spirit from someone
else.
--
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
* Re: [RFD] gitweb configuration
From: Petr Baudis @ 2006-06-17 23:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e720r0$qdv$1@sea.gmane.org>
Dear diary, on Sun, Jun 18, 2006 at 12:48:12AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis <pasky@suse.cz> writes:
> > - 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).
(Note that this is what Junio said, not me.)
> - gitweb installation options (gitweb version need not to correspond to
> git version, and we could theoretically have more than one gitweb
> installation while one git-core installation). It was proposed to put
> such options on gitweb.conf file in the same directory as gitweb.cgi.
> Unfortunately if one would want to use git-repo-config for managing
> gitweb.conf one is out of luck: git-repo-config uses $GIT_DIR/config.
In the longer term, perhaps this kind of configuration might land in the
global git configuration file.
---
[PATCH] Support for extracting configuration from different files
Add $GIT_CONFIG environment variable whose content is used instead
of .git/config if set. Also add $GIT_CONFIG_LOCAL as a
forward-compatibility cue for whenever we will finally come to support]
global configuration files (properly).
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-repo-config.txt | 12 ++++++++++++
config.c | 12 +++++++++++-
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
index d5142e0..803c0d5 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -73,6 +73,18 @@ OPTIONS
List all variables set in .git/config.
+ENVIRONMENT
+-----------
+
+GIT_CONFIG::
+ Take the configuration from the given file instead of .git/config.
+
+GIT_CONFIG_LOCAL::
+ Currently the same as $GIT_CONFIG; when Git will support global
+ configuration files, this will cause it to take the configuration
+ from the global configuration file in addition to the given file.
+
+
EXAMPLE
-------
diff --git a/config.c b/config.c
index c474970..42e1493 100644
--- a/config.c
+++ b/config.c
@@ -317,7 +317,17 @@ int git_config_from_file(config_fn_t fn,
int git_config(config_fn_t fn)
{
- return git_config_from_file(fn, git_path("config"));
+ const char *filename = git_path("config");
+ /* Forward-compatibility cue: $GIT_CONFIG makes git read _only_
+ * the given config file, $GIT_CONFIG_LOCAL will make it process
+ * it in addition to the global config file, the same way it would
+ * the per-repository config file otherwise. */
+ if (getenv("GIT_CONFIG")) {
+ filename = getenv("GIT_CONFIG");
+ } else if (getenv("GIT_CONFIG_LOCAL")) {
+ filename = getenv("GIT_CONFIG_LOCAL");
+ }
+ return git_config_from_file(fn, filename);
}
/*
--
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 related
* [ANNOUNCE] Cogito-0.17.3
From: Petr Baudis @ 2006-06-18 0:19 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
cogito-0.17.3 was just released - bugfixes release on the latest
stable line of the Cogito user-friendly Git user interface.
Plenty of new stuff, mostly bugfixes - especially cg-admin-rewritehist
was particularily bug-ridden and Git 1.4.0 broke some backwards
compatibility, Cogito 0.17.3 should work smoothly with it again.
So, what's new?
* Many cg-admin-rewritehist bugfixes; note that -r semantics was
changed to match documentation, -k steps in to mean what -r used
to in practice
* Some documentation fixes
* Adjust to some Git 1.4.0 usage changes and new-style git-http-push
* Several other random things
Who did what:
Bertrand Jacquin:
Push over HTTP now works with refs/heads/foo instead of foo
Dennis Stosberg:
cg-clean fails on files beginning with a dash
Johannes Sixt:
cg-admin-rewritehist: Seed the commit map with the parents specified with -r
Enhance the rewritemap seeding when given symbolic commit ids
cg-admin-rewritehist: fix reappearing files with --filter-tree
cg-admin-rewritehist: Add the documented but missing --msg-filter option.
cg-admin-rewritehist: Must use the parent of the start rev to seed the map.
cg-admin-rewritehist: Support multiple parents of the start revision (-r).
cg-admin-rewritehist: Support partial rewriting of complicated history.
Jonas Fonseca:
ciabot: fix post-update hook description
Portfile: bring it up to date; use description from cogito.spec.in
Minor doc fixes
Fix section slicing so help options are not misplaced in cg-commit(1)
Martin Langhoff:
cg-status -- disambiguate parameters to git-diff-files
Pavel Roskin:
Fix cg-status with recent git versions
[PATCH 1/2] Fix cg-patch hanging on terminals with TOSTOP flag
[PATCH 2/2] Improve the tutorial script
Petr Baudis:
mkdir -p .git/info since git-init-db won't always create it
Separate git-diff-* file arguments by --
Export the $PATH we've set
Use local Cogito version when running the tutorial script
Fix cg-rm -r in a subdirectory
Do not export relpath - fixes cg-add -r in a subdir
Fix output of cg-status path with path given w/o trailing slash
cg-status: do not strip subdirs given in path specifier
Make cg-rm -r subdir fix actually safe
Fix broken tree timewarp with late git versions
Use tail -n +2 inst. of tail +2
Make testcases take input from /dev/null
Fix cg-tag calls changed by the backported update
Fix cg-admin-rewritehist -r
Indentation fix
cg-admin-rewritehist: Die in case of invalid revisions
cogito-0.17.3
Yann Dirson:
[PATCH 2/2] Catch history inconsistency in cg-admin-rewritehist
Fix cg-object-id to lookup parents in the Right Way
[PATCH 1/3] cg-admin-rewritehist: catch git-rev-list returning no commit
P.S.: See us at #git @ FreeNode!
Happy hacking,
--
Petr "Pasky the lousy poet" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ 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