* Re: Closing the merge window for 1.6.0
@ 2008-07-15 17:28 4% ` Petr Baudis
0 siblings, 0 replies; 35+ results
From: Petr Baudis @ 2008-07-15 17:28 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin, Dmitry Potapov, Junio C Hamano, Gerrit Pape,
git
On Tue, Jul 15, 2008 at 12:26:48PM -0400, Nicolas Pitre wrote:
> Anyway this is all hand waving until someone can come with some evidence
> that git 1.4.4 is actually used by a significant amount of people, and
> that those people depend on dumb transfer protocols.
That will be hard to produce. :-) _My_ personal story is that I have
Git-1.4.4.4 installed system-wide on repo.or.cz and follow git#next
locally, and quite panicked when I was inspecting some repositories
as root (using the system-wide Git) and these error messages popped up.
This may become a similar experience for others on multi-user systems
where people want to share work but don't realize that one of them has
Git installed locally and the other one doesn't. We can save them the
head-slapping and a bit of wasted life.
Out of interest, I did a simple statistics of HTTP user agents on
repo.or.cz; the dumb access does not seem very widely used overally,
it turns out. The stats begin at 19/May/2008:10:54:32 +0200. Here is the
breakdown, counting unique clients only:
# zgrep '"GET /r/.*/info/packs' /var/log/apache2/repo-access.log* | egrep -v bot\|slurp\|Gecko\|Opera |
cut -d " " -f 1,12- | sed 's/\.g[a-f0-9]*\(\.dirty\)*"/"/' | sort -u |
cut -d ' ' -f 2 | sort | uniq -c | sort -rn | head -n 50
1501 "git/1.5.4.3" <- Ubuntu Hardy (heh.. is just that it?)
278 "git/1.5.5.1" <- RHEL5 (ditto)
151 "git/1.5.2.5" <- Ubuntu Gutsy
133 "git/1.5.5.3" <- ? (maybe Gentoo ~x86 for some time)
125 "git/1.5.4.5" <- OpenSUSE 11.0, FC9, Gentoo x86, Dapper backports
104 "git/1.5.6" <- Debian Lenny
94 "git/1.5.5"
66 "git/1.5.3.7"
63 "git/1.5.5.4"
63 "git/1.5.5.1015"
55 "git/1.5.2.4" <- OpenSUSE 10.3
51 "Mozilla/4.0 (compatible;)" <- huh?
42 "git/1.5.3.8"
37 "git/1.5.5.GIT"
37 "git/1.5.3.5.2229"
34 "git/1.5.6.1"
33 "git/1.5.3.6" <- Feisty backports
31 "git/1.5.4.1"
30 "git/1.5.6.2"
20 "git/1.5.6.GIT"
18 "git/1.5.3"
17 "git/1.5.2.2"
17 "git/1.4.4.4"
15 "git/1.5.6.1.1071"
14 "git/1.5.3.3"
13 "git/1.5.4.4"
13 "git/1.5.4"
11 "git/1.5.6.1062"
11 "git/1.5.5.2"
10 "git/1.5.5.1.316"
(I also got two 1.4.4.2 (feisty?) fetches from one client. No older
Git versions.)
So wrt. keeping backwards compatibility, this is not _very_ convincing,
I admit. ;-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply [relevance 4%]
* git on Cygwin: Not a valid object name HEAD
@ 2007-08-07 9:02 6% Sebastian Schuberth
0 siblings, 0 replies; 35+ results
From: Sebastian Schuberth @ 2007-08-07 9:02 UTC (permalink / raw)
To: git
Hi,
I'm running git 1.5.2.2 under Cygwin on Windows XP. This is what I'm
(reproducibly) getting if I try to clone QGit's repository:
sschuber@xp-sschuber2 ~
$ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git
Initialized empty Git repository in /home/sschuber/qgit4/.git/
remote: Generating pack...
remote: Done counting 2295 objects.
remote: Deltifying 2295 objects...
remote: 100% (2295/2295) done
Indexing 2295 objects...
remote: Total 2295 (delta 1793), reused 1218 (delta 955)
100% (2295/2295) done
Resolving 1793 deltas...
100% (1793/1793) done
: not a valid SHA1b870df7cde1e05ee76d1d15ea428f
fatal: Not a valid object name HEAD
sschuber@xp-sschuber2 ~
$ git --version
git version 1.5.2.2
I'm not sure whether the cause for this is the same as mentioned at
http://article.gmane.org/gmane.comp.version-control.git/54825
However, the most recent msysGit worked fine for me. Any clues whether
this is a repository problem, a Cygwin problem, or a git problem?
Thanks.
--
Sebastian Schuberth
^ permalink raw reply [relevance 6%]
* Re: cg switch -l doesn't work when branches point to the same commit
@ 2007-07-11 13:36 5% ` Alex Riesen
0 siblings, 0 replies; 35+ results
From: Alex Riesen @ 2007-07-11 13:36 UTC (permalink / raw)
To: Bradford Smith; +Cc: git
On 7/11/07, Bradford Smith <bradford.carl.smith@gmail.com> wrote:
> The message below applies to software versions:
>
> git version 1.4.4.2
It is fixed sometime between your version and git-1.5.2.2.
Use git checkout.
> cogito-0.18.2
Cogito is unmaintained ATM.
^ permalink raw reply [relevance 5%]
* Re: gitk doesn't start due to cygwin wish not following symlinks?
2007-07-03 19:02 6% gitk doesn't start due to cygwin wish not following symlinks? Kees-Jan Dijkzeul
@ 2007-07-06 9:33 5% ` Jan Hudec
0 siblings, 0 replies; 35+ results
From: Jan Hudec @ 2007-07-06 9:33 UTC (permalink / raw)
To: Kees-Jan Dijkzeul; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]
On Tue, Jul 03, 2007 at 21:02:35 +0200, Kees-Jan Dijkzeul wrote:
> Hi,
>
> I'm using "stow" to manage several versions of git on my cygwin
> system. As a result, my /usr/local/bin contains a bunch of symlinks to
> the actual binaries in /usr/local/stow/git-1.5.2.2/bin.
>
> This works like a charm, except that gitk won't start up, claiming, in
> turn, that it is unable to start git itself. After some investigation,
> I found that the "wish" that is supplied with cygwin isn't a true
> cygwin one, and hence doesn't understand cygwin style simlinks, and
> thus cannot start the /usr/local/bin/git symlink. It needs the true
> binary.
>
> So for now, I've worked around this by updating the first few lines of
> the gitk script to read:
>
> #!/bin/sh
> # Tcl ignores the next line -*- tcl -*- \
> export PATH=$PATH:/usr/local/stow/git-1.5.2.2/bin
> # Tcl ignores the next line also \
> exec wish "$0" -- "$@"
>
> This works for me, but is admittedly butt-ugly. Any tips on how to
> handle this kind of situation?
Ask cygwin folks to teach their wish their symlinks?
You could also try putting a git.bat somewhere in path, that would set the
path and run true git from /usr/local/stow/git-1.5.2.2/bin.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [relevance 5%]
* gitk doesn't start due to cygwin wish not following symlinks?
@ 2007-07-03 19:02 6% Kees-Jan Dijkzeul
2007-07-06 9:33 5% ` Jan Hudec
0 siblings, 1 reply; 35+ results
From: Kees-Jan Dijkzeul @ 2007-07-03 19:02 UTC (permalink / raw)
To: git
Hi,
I'm using "stow" to manage several versions of git on my cygwin
system. As a result, my /usr/local/bin contains a bunch of symlinks to
the actual binaries in /usr/local/stow/git-1.5.2.2/bin.
This works like a charm, except that gitk won't start up, claiming, in
turn, that it is unable to start git itself. After some investigation,
I found that the "wish" that is supplied with cygwin isn't a true
cygwin one, and hence doesn't understand cygwin style simlinks, and
thus cannot start the /usr/local/bin/git symlink. It needs the true
binary.
So for now, I've worked around this by updating the first few lines of
the gitk script to read:
#!/bin/sh
# Tcl ignores the next line -*- tcl -*- \
export PATH=$PATH:/usr/local/stow/git-1.5.2.2/bin
# Tcl ignores the next line also \
exec wish "$0" -- "$@"
This works for me, but is admittedly butt-ugly. Any tips on how to
handle this kind of situation?
Thanks a lot!
Groetjes,
Kees-Jan
^ permalink raw reply [relevance 6%]
* What's in git.git (stable)
@ 2007-06-21 7:21 6% ` Junio C Hamano
0 siblings, 0 replies; 35+ results
From: Junio C Hamano @ 2007-06-21 7:21 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (1):
Add a local implementation of hstrerror for the system which do not have it
Jakub Narebski (1):
Generated spec file to be ignored is named git.spec and not git-core.spec
Johannes Schindelin (2):
Move buffer_is_binary() to xdiff-interface.h
merge-recursive: refuse to merge binary files
Junio C Hamano (5):
$EMAIL is a last resort fallback, as it's system-wide.
git-branch --track: fix tracking branch computation.
Avoid diff cost on "git log -z"
Documentation: adjust to AsciiDoc 8
GIT 1.5.2.2
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (2):
Do not use h_errno after connect(2): the function does not set it
cvsserver: Actually implement --export-all
Daniel Barkalow (1):
Fix pushing to a pattern with no dst
Frank Lichtenheld (3):
cvsserver: Add some useful commandline options
cvsserver: Let --base-path and pserver get along just fine
cvsserver: Actually implement --export-all
Gerrit Pape (1):
git-branch: cleanup config file when deleting branches
Ismail Dönmez (1):
Change default man page path to /usr/share/man
Jakub Narebski (8):
Document git rev-list --full-history
Document git read-tree --trivial
Document git rev-parse --is-inside-git-dir
Document git reflog --stale-fix
Document git rev-list --timestamp
Use tabs for indenting definition list for options in git-log.txt
Document git log --abbrev-commit, as a kind of pretty option
Document git log --full-diff
Junio C Hamano (8):
remote.c: refactor match_explicit_refs()
remote.c: refactor creation of new dst ref
remote.c: minor clean-up of match_explicit()
remote.c: fix "git push" weak match disambiguation
remote.c: "git-push frotz" should update what matches at the source.
git-push: Update description of refspecs and add examples
Documentation: update "stale" links for 1.5.2.2
INSTALL: explain how to build documentation
Lars Hjemli (6):
t7400: barf if git-submodule removes or replaces a file
git-submodule: remember to checkout after clone
Rename sections from "module" to "submodule" in .gitmodules
git-submodule: give submodules proper names
Add gitmodules(5)
gitmodules(5): remove leading period from synopsis
Sam Vilain (1):
git-svn: avoid string eval for defining functions
^ permalink raw reply [relevance 6%]
* Re: [ANNOUNCE] GIT 1.5.2.2
2007-06-17 1:57 10% [ANNOUNCE] GIT 1.5.2.2 Junio C Hamano
2007-06-17 10:30 5% ` Arkadiusz Miskiewicz
2007-06-18 3:27 6% ` Shawn O. Pearce
@ 2007-06-20 8:34 6% ` Jakub Narebski
2 siblings, 0 replies; 35+ results
From: Jakub Narebski @ 2007-06-20 8:34 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> - git-gui is shipped with its updated blame interface. It is
> rumored that the older one was not just unusable but was
> active health hazard, but this one is actually pretty.
> Please see for yourself.
I like the new interface very much, especially the info about who
made the change, and who moved the change to present place.
It would be nice though to have git-gui(1) man page describing 'blame'
subcommand of git-gui,, or have "git blame --gui" invoke "git gui blame".
gitk has it's manpage, why not git-gui? AFAICT there is currently no way to
discover this wonderfull tool given only manpages and git-gui help.
Perhaps file browser in git-gui should have "Blame"/"Annotate" button?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [relevance 6%]
* Re: Errors install git-1.5.2.2 on 64-bit AIX
2007-06-20 3:21 6% ` Linus Torvalds
@ 2007-06-20 3:36 6% ` Dongsheng Song
0 siblings, 0 replies; 35+ results
From: Dongsheng Song @ 2007-06-20 3:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
No "ginstall" or "gnuinstall". I will try compile coreutils-6.9 latter.
2007/6/20, Linus Torvalds <torvalds@linux-foundation.org>:
>
>
> On Wed, 20 Jun 2007, Dongsheng Song wrote:
> >
> > But install failed:
> > [ ... ]
> > Usage: install [-c dira] [-f dirb] [-i] [-m] [-M mode] [-O owner]
> > [-G group] [-S] [-n dirc] [-o] [-s] file [dirx ...]
> > gnumake: *** [install] Error 2
>
> Do you possibly have a "ginstall" somewhere in addition to the GNU make?
>
> If so, just make the "INSTALL" macro in the Makefile point to that instead
> of the (apparently totally broken) regular "install" program on AIX.
>
> Maybe it's called "gnuinstall".
>
> That said, the installation is really just a matter of copying, so you
> *could* just replace the uses of "install" with either "-mkdir" or "cp"
> depending on whether it's used to make sure a directory exists, or to
> actually copy the programs.
>
> Linus
>
^ permalink raw reply [relevance 6%]
* Re: Errors install git-1.5.2.2 on 64-bit AIX
2007-06-20 2:45 5% Errors install git-1.5.2.2 on 64-bit AIX Dongsheng Song
@ 2007-06-20 3:21 6% ` Linus Torvalds
2007-06-20 3:36 6% ` Dongsheng Song
0 siblings, 1 reply; 35+ results
From: Linus Torvalds @ 2007-06-20 3:21 UTC (permalink / raw)
To: Dongsheng Song; +Cc: Junio C Hamano, Git Mailing List
On Wed, 20 Jun 2007, Dongsheng Song wrote:
>
> But install failed:
> [ ... ]
> Usage: install [-c dira] [-f dirb] [-i] [-m] [-M mode] [-O owner]
> [-G group] [-S] [-n dirc] [-o] [-s] file [dirx ...]
> gnumake: *** [install] Error 2
Do you possibly have a "ginstall" somewhere in addition to the GNU make?
If so, just make the "INSTALL" macro in the Makefile point to that instead
of the (apparently totally broken) regular "install" program on AIX.
Maybe it's called "gnuinstall".
That said, the installation is really just a matter of copying, so you
*could* just replace the uses of "install" with either "-mkdir" or "cp"
depending on whether it's used to make sure a directory exists, or to
actually copy the programs.
Linus
^ permalink raw reply [relevance 6%]
* Errors install git-1.5.2.2 on 64-bit AIX
@ 2007-06-20 2:45 5% Dongsheng Song
2007-06-20 3:21 6% ` Linus Torvalds
0 siblings, 1 reply; 35+ results
From: Dongsheng Song @ 2007-06-20 2:45 UTC (permalink / raw)
Cc: Junio C Hamano, git
After I modified Makefile:
NO_OPENSSL=1
NO_CURL=1
NO_EXPAT=1
CFLAGS = -maix64 -g -O2 -Wall
LDFLAGS = -b64 -lz
AR = ar -X64
Make succeed:
bash-3.00# gnumake
GIT_VERSION = 1.5.2.2
* new build flags or prefix
CC convert-objects.o
...
SUBDIR perl
cp private-Error.pm blib/lib/Error.pm
cp Git.pm blib/lib/Git.pm
Manifying blib/man3/private-Error.3
Manifying blib/man3/Git.3
SUBDIR templates
gcc -maix64 -g -O2 -Wall -DNO_OPENSSL
-DSHA1_HEADER='"mozilla-sha1/sha1.h"'
-DETC_GITCONFIG='"/usr/git/etc/gitconfig"' -DNO_STRCASESTR
-DNO_STRLCPY -o test-chmtime -lz test-chmtime.c
gcc -maix64 -g -O2 -Wall -DNO_OPENSSL
-DSHA1_HEADER='"mozilla-sha1/sha1.h"'
-DETC_GITCONFIG='"/usr/git/etc/gitconfig"' -DNO_STRCASESTR
-DNO_STRLCPY -o test-genrandom -lz test-genrandom.c
But install failed:
bash-3.00# gnumake install
SUBDIR git-gui
SUBDIR perl
SUBDIR templates
install -d -m755 '/usr/git/bin'
getopt: illegal option -- d
getopt: illegal option -- 7
getopt: illegal option -- 5
getopt: illegal option -- 5
Usage: install [-c dira] [-f dirb] [-i] [-m] [-M mode] [-O owner]
[-G group] [-S] [-n dirc] [-o] [-s] file [dirx ...]
gnumake: *** [install] Error 2
Thanks for some help.
---
Dongsheng
^ permalink raw reply [relevance 5%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 21:11 6% ` Junio C Hamano
@ 2007-06-19 21:17 6% ` Bill Lear
0 siblings, 0 replies; 35+ results
From: Bill Lear @ 2007-06-19 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Kastrup
On Tuesday, June 19, 2007 at 14:11:32 (-0700) Junio C Hamano writes:
>...
>A one-word guess: CDPATH.
A one-word reply: that-was-correct-thank-you-and-good-guess.
Bill
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 20:57 3% ` Bill Lear
@ 2007-06-19 21:11 6% ` Johannes Schindelin
0 siblings, 0 replies; 35+ results
From: Johannes Schindelin @ 2007-06-19 21:11 UTC (permalink / raw)
To: Bill Lear; +Cc: Alex Riesen, David Kastrup, git
Hi,
On Tue, 19 Jun 2007, Bill Lear wrote:
> (cd blt && tar cf - .) | od -a | head -50
>
> Here is the result of that:
>
> 0000000 / h o m e / b l e a r / b u i l
> 0000020 d / g i t - 1 . 5 . 2 . 2 / t e
> 0000040 m p l a t e s / b l t nl . / nul nul
> 0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
As is easy to see, what has been suggested earlier is true. The cd
(idiotically) outputs the path to stdout.
Hth,
Dscho
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 15:12 6% ` David Kastrup
2007-06-19 16:16 12% ` Bill Lear
@ 2007-06-19 21:11 6% ` Junio C Hamano
2007-06-19 21:17 6% ` Bill Lear
1 sibling, 1 reply; 35+ results
From: Junio C Hamano @ 2007-06-19 21:11 UTC (permalink / raw)
To: Bill Lear; +Cc: git, David Kastrup
David Kastrup <dak@gnu.org> writes:
> Not sure whether this is the problem: either cd does not understasnd
> the double slashes, or your shell used for scripts has modified cd to
> output some stuff when it is working (people sometimes imprudently
> make shell functions or aliases for this).
>
> Try writing something like
>
> type cd
>
> in a script file and see what output you get.
A one-word guess: CDPATH.
Bill, setting CDPATH in your interactive shell as a shell
variable is Ok, but exporting it as an environment does not make
much sense.
Really.
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 20:09 6% ` Alex Riesen
@ 2007-06-19 20:57 3% ` Bill Lear
2007-06-19 21:11 6% ` Johannes Schindelin
0 siblings, 1 reply; 35+ results
From: Bill Lear @ 2007-06-19 20:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: David Kastrup, git
On Tuesday, June 19, 2007 at 22:09:39 (+0200) Alex Riesen writes:
>Bill Lear, Tue, Jun 19, 2007 18:16:26 +0200:
>> % cat foo
>> set -x
>> type tar
>> type cd
>> (cd blt && tar cf - .) | (cd /opt/git-1.5.2.2/share/git-core/templates && tar xf -)
>
>what would you see if your script contained:
>
> set -x
> (cd blt && tar cf - .) |less
>
>?
>Does the output look like a tar archive to you?
Well, not sure. Lots of gobbledygook.
>Can you share it with us if you're not sure?
Ok, I've tried to send a limited amount of data, hopefully useful. If
I redirect to a file:
(cd blt && tar cf - .) > tar.tar
and then try to view it with tar:
% tar tvf tar.tar
I get the same error as before. I sent the output through
'od' as so:
(cd blt && tar cf - .) | od -a | head -50
Here is the result of that:
0000000 / h o m e / b l e a r / b u i l
0000020 d / g i t - 1 . 5 . 2 . 2 / t e
0000040 m p l a t e s / b l t nl . / nul nul
0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000220 0 0 0 0 7 5 5 nul 0 0 0 1 3 5 0 nul
0000240 0 0 0 0 1 5 4 nul 0 0 0 0 0 0 0 0
0000260 0 0 0 nul 1 0 6 3 5 7 6 5 2 7 4 nul
0000300 0 1 0 7 2 4 nul sp 5 nul nul nul nul nul nul nul
0000320 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000440 nul nul nul nul nul nul nul nul nul nul nul nul nul u s t
0000460 a r sp sp nul b l e a r nul nul nul nul nul nul
0000500 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000520 nul nul nul nul nul s o f t w a r e nul nul nul
0000540 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001040 nul nul nul nul nul nul nul nul nul nul nul nul . / d e
0001060 s c r i p t i o n nul nul nul nul nul nul nul
0001100 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001220 0 0 0 0 6 4 4 nul 0 0 0 1 3 5 0 nul
0001240 0 0 0 0 1 5 4 nul 0 0 0 0 0 0 0 0
0001260 0 7 2 nul 1 0 6 3 5 7 6 5 2 7 4 nul
0001300 0 1 3 1 7 1 nul sp 0 nul nul nul nul nul nul nul
0001320 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001440 nul nul nul nul nul nul nul nul nul nul nul nul nul u s t
0001460 a r sp sp nul b l e a r nul nul nul nul nul nul
0001500 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0001520 nul nul nul nul nul s o f t w a r e nul nul nul
0001540 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0002040 nul nul nul nul nul nul nul nul nul nul nul nul U n n a
0002060 m e d sp r e p o s i t o r y ; sp
0002100 e d i t sp t h i s sp f i l e sp t
0002120 o sp n a m e sp i t sp f o r sp g i
0002140 t w e b . nl nul nul nul nul nul nul nul nul nul nul
0002160 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0003040 nul nul nul nul nul nul nul nul nul nul nul nul . / b r
0003060 a n c h e s / nul nul nul nul nul nul nul nul nul
0003100 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0003220 0 0 0 0 7 5 5 nul 0 0 0 1 3 5 0 nul
0003240 0 0 0 0 1 5 4 nul 0 0 0 0 0 0 0 0
0003260 0 0 0 nul 1 0 6 3 5 7 6 5 2 7 3 nul
0003300 0 1 2 5 1 0 nul sp 5 nul nul nul nul nul nul nul
0003320 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
If I run this from the command-line, instead of a script, I get
this (and if it is redirected to a file instead of 'od', tar
can read it):
0000000 . / nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000140 nul nul nul nul 0 0 0 0 7 5 5 nul 0 0 0 1
0000160 3 5 0 nul 0 0 0 0 1 5 4 nul 0 0 0 0
0000200 0 0 0 0 0 0 0 nul 1 0 6 3 5 7 6 5
0000220 2 7 4 nul 0 1 0 7 2 4 nul sp 5 nul nul nul
0000240 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000400 nul u s t a r sp sp nul b l e a r nul nul
0000420 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000440 nul nul nul nul nul nul nul nul nul s o f t w a r
0000460 e nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000500 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001000 . / d e s c r i p t i o n nul nul nul
0001020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001140 nul nul nul nul 0 0 0 0 6 4 4 nul 0 0 0 1
0001160 3 5 0 nul 0 0 0 0 1 5 4 nul 0 0 0 0
0001200 0 0 0 0 0 7 2 nul 1 0 6 3 5 7 6 5
0001220 2 7 4 nul 0 1 3 1 7 1 nul sp 0 nul nul nul
0001240 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001400 nul u s t a r sp sp nul b l e a r nul nul
0001420 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0001440 nul nul nul nul nul nul nul nul nul s o f t w a r
0001460 e nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0001500 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0002000 U n n a m e d sp r e p o s i t o
0002020 r y ; sp e d i t sp t h i s sp f i
0002040 l e sp t o sp n a m e sp i t sp f o
0002060 r sp g i t w e b . nl nul nul nul nul nul nul
0002100 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0003000 . / b r a n c h e s / nul nul nul nul nul
0003020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0003140 nul nul nul nul 0 0 0 0 7 5 5 nul 0 0 0 1
0003160 3 5 0 nul 0 0 0 0 1 5 4 nul 0 0 0 0
0003200 0 0 0 0 0 0 0 nul 1 0 6 3 5 7 6 5
0003220 2 7 3 nul 0 1 2 5 1 0 nul sp 5 nul nul nul
0003240 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0003400 nul u s t a r sp sp nul b l e a r nul nul
0003420 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0003440 nul nul nul nul nul nul nul nul nul s o f t w a r
0003460 e nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0003500 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
Bill
^ permalink raw reply [relevance 3%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 16:16 12% ` Bill Lear
@ 2007-06-19 20:09 6% ` Alex Riesen
2007-06-19 20:57 3% ` Bill Lear
0 siblings, 1 reply; 35+ results
From: Alex Riesen @ 2007-06-19 20:09 UTC (permalink / raw)
To: Bill Lear; +Cc: David Kastrup, git
Bill Lear, Tue, Jun 19, 2007 18:16:26 +0200:
> % cat foo
> set -x
> type tar
> type cd
> (cd blt && tar cf - .) | (cd /opt/git-1.5.2.2/share/git-core/templates && tar xf -)
what would you see if your script contained:
set -x
(cd blt && tar cf - .) |less
?
Does the output look like a tar archive to you?
Can you share it with us if you're not sure?
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 15:12 6% ` David Kastrup
@ 2007-06-19 16:16 12% ` Bill Lear
2007-06-19 20:09 6% ` Alex Riesen
2007-06-19 21:11 6% ` Junio C Hamano
1 sibling, 1 reply; 35+ results
From: Bill Lear @ 2007-06-19 16:16 UTC (permalink / raw)
To: David Kastrup; +Cc: git
On Tuesday, June 19, 2007 at 17:12:14 (+0200) David Kastrup writes:
>Bill Lear <rael@zopyra.com> writes:
>>...
>> However, I still get this:
>>
>> install -d -m755 '/opt/git-1.5.2.2/share//git-core/templates/'
> ^^^
>> (cd blt && tar cf - .) | \
>> (cd '/opt/git-1.5.2.2/share//git-core/templates/' && tar xf -)
> ^^^
>> tar: This does not look like a tar archive
>> tar: Skipping to next header
>> tar: Archive contains obsolescent base-64 headers
>> tar: Error exit delayed from previous errors
>>
>> So, I did a make -k and it worked ok, aside from this error.
>>
>> I copied this line:
>>
>> (cd blt && tar cf - .) | \
>> (cd '/opt/git-1.5.2.2/share//git-core/templates/' && tar xf -)
> ^^^
>> into a file, chmod +x'd that file, and cd'd into templates and ran
>> the script. I got the same error. I then tried running it by
>> hand from the command line:
>>
>> % cd templates
>> % (cd blt && tar cf - .) | (cd /opt/git-1.5.2.2/share/git-core/templates
>> ^^^
>> && tar xf -)
>>
>> and it worked fine.
>
>Not sure whether this is the problem: either cd does not understasnd
>the double slashes, or your shell used for scripts has modified cd to
>output some stuff when it is working (people sometimes imprudently
>make shell functions or aliases for this).
>
>Try writing something like
>
>type cd
>
>in a script file and see what output you get.
% echo 'type cd' > foo
% chmod +x foo
% ./foo
cd is a shell builtin
% bash --version
GNU bash, version 3.1.17(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
I also tried using the double-slash on the command line. It worked
fine. I tried a single slash from the script and it did not work.
% cd templates
% cat foo
set -x
type tar
type cd
(cd blt && tar cf - .) | (cd /opt/git-1.5.2.2/share/git-core/templates && tar xf -)
% ./foo
++ type tar
tar is /bin/tar
++ type cd
cd is a shell builtin
++ cd blt
++ tar cf - .
++ cd /opt/git-1.5.2.2/share/git-core/templates
++ tar xf -
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Error exit delayed from previous errors
Bill
^ permalink raw reply [relevance 12%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 14:48 13% ` Bill Lear
@ 2007-06-19 15:12 6% ` David Kastrup
2007-06-19 16:16 12% ` Bill Lear
2007-06-19 21:11 6% ` Junio C Hamano
0 siblings, 2 replies; 35+ results
From: David Kastrup @ 2007-06-19 15:12 UTC (permalink / raw)
To: git
Bill Lear <rael@zopyra.com> writes:
> On Tuesday, June 19, 2007 at 16:30:00 (+0200) Marco Roeland writes:
>>On Tuesday June 19th 2007 at 08:50 Bill Lear wrote:
>>>
>>> I checked and there is no iconv package (rpm). I really don't want
>>> to have to temporarily rename a header. I can't hand this out to
>>> the rest of the company, some of whom do not have root access to
>>> be able to rename header files.
>>
>>You might at least investigate if there is somehow another iconv.h
>>header besides the system one under /usr/include, that might have been
>>used by the compiler instead of the standard one from GNU libc.
>
> Ok, I moved all the *iconv* stuff in /usr/local/<blah> and now
> it builds ok.
>
> However, I still get this:
>
> install -d -m755 '/opt/git-1.5.2.2/share//git-core/templates/'
^^^
> (cd blt && tar cf - .) | \
> (cd '/opt/git-1.5.2.2/share//git-core/templates/' && tar xf -)
^^^
> tar: This does not look like a tar archive
> tar: Skipping to next header
> tar: Archive contains obsolescent base-64 headers
> tar: Error exit delayed from previous errors
>
> So, I did a make -k and it worked ok, aside from this error.
>
> I copied this line:
>
> (cd blt && tar cf - .) | \
> (cd '/opt/git-1.5.2.2/share//git-core/templates/' && tar xf -)
^^^
> into a file, chmod +x'd that file, and cd'd into templates and ran
> the script. I got the same error. I then tried running it by
> hand from the command line:
>
> % cd templates
> % (cd blt && tar cf - .) | (cd /opt/git-1.5.2.2/share/git-core/templates
> ^^^
> && tar xf -)
>
> and it worked fine.
Not sure whether this is the problem: either cd does not understasnd
the double slashes, or your shell used for scripts has modified cd to
output some stuff when it is working (people sometimes imprudently
make shell functions or aliases for this).
Try writing something like
type cd
in a script file and see what output you get.
--
David Kastrup
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 13:58 6% ` Johannes Schindelin
@ 2007-06-19 14:13 6% ` David Kastrup
0 siblings, 0 replies; 35+ results
From: David Kastrup @ 2007-06-19 14:13 UTC (permalink / raw)
To: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 19 Jun 2007, Bill Lear wrote:
>
>> On Tuesday, June 19, 2007 at 14:00:07 (+0100) Johannes Schindelin writes:
>> >
>> >On Tue, 19 Jun 2007, Bill Lear wrote:
>> >
>> >> Also breaks (tar fails) if I do the 'make configure; ./configure'
>> >> route.
>> >
>> >Then there is a test missing in configure.
>>
>> Here is the particular error:
>>
>> install git '/opt/git-1.5.2.2/bin'
>> make -C templates DESTDIR='' install
>> make[1]: Entering directory `/home/blear/build/git-1.5.2.2/templates'
>> install -d -m755 '/opt/git-1.5.2.2/share/git-core/templates/'
>> (cd blt && gtar cf - .) | \
>> (cd '/opt/git-1.5.2.2/share/git-core/templates/' && gtar xf -)
>> gtar: This does not look like a tar archive
>> gtar: Skipping to next header
>> gtar: Archive contains obsolescent base-64 headers
>> gtar: Error exit delayed from previous errors
>> make[1]: *** [install] Error 2
>> make[1]: Leaving directory `/home/blear/build/git-1.5.2.2/templates'
>> make: *** [install] Error 2
>
> WTF? gtar cannot read its own output?
>
> Be that as may, this is not git error.
It is possible that cd is an alias outputting the target of cd.
People do those kind of things. It is also possible that the first cd
fails and thus the first gtar is not run (though tar xf /dev/null is
quiet here, so probably should be at the OP's site, too.).
--
David Kastrup
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 14:30 6% ` Marco Roeland
@ 2007-06-19 14:48 13% ` Bill Lear
2007-06-19 15:12 6% ` David Kastrup
0 siblings, 1 reply; 35+ results
From: Bill Lear @ 2007-06-19 14:48 UTC (permalink / raw)
To: Marco Roeland; +Cc: Johannes Schindelin, git
On Tuesday, June 19, 2007 at 16:30:00 (+0200) Marco Roeland writes:
>On Tuesday June 19th 2007 at 08:50 Bill Lear wrote:
>>
>> I checked and there is no iconv package (rpm). I really don't want
>> to have to temporarily rename a header. I can't hand this out to
>> the rest of the company, some of whom do not have root access to
>> be able to rename header files.
>
>You might at least investigate if there is somehow another iconv.h
>header besides the system one under /usr/include, that might have been
>used by the compiler instead of the standard one from GNU libc.
Ok, I moved all the *iconv* stuff in /usr/local/<blah> and now
it builds ok.
However, I still get this:
install -d -m755 '/opt/git-1.5.2.2/share//git-core/templates/'
(cd blt && tar cf - .) | \
(cd '/opt/git-1.5.2.2/share//git-core/templates/' && tar xf -)
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Error exit delayed from previous errors
So, I did a make -k and it worked ok, aside from this error.
I copied this line:
(cd blt && tar cf - .) | \
(cd '/opt/git-1.5.2.2/share//git-core/templates/' && tar xf -)
into a file, chmod +x'd that file, and cd'd into templates and ran
the script. I got the same error. I then tried running it by
hand from the command line:
% cd templates
% (cd blt && tar cf - .) | (cd /opt/git-1.5.2.2/share/git-core/templates && tar xf -)
and it worked fine.
Bill
^ permalink raw reply [relevance 13%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 13:50 6% ` Bill Lear
@ 2007-06-19 14:30 6% ` Marco Roeland
2007-06-19 14:48 13% ` Bill Lear
0 siblings, 1 reply; 35+ results
From: Marco Roeland @ 2007-06-19 14:30 UTC (permalink / raw)
To: Bill Lear; +Cc: Johannes Schindelin, git
On Tuesday June 19th 2007 at 08:50 Bill Lear wrote:
> Well, I'll try that, but this is a fresh install of Centos 5, not a
> custom-hacked OS, and I would think that git should build out of the
> box on it.
Yes it should, but your error messages do suggest there is a mismatch
between headers and libraries for the iconv functions. And as on Linux
those are in libc, which is always linked in, it suggests there is a roque
header perhaps!
>
> I checked and there is no iconv package (rpm). I really don't want
> to have to temporarily rename a header. I can't hand this out to
> the rest of the company, some of whom do not have root access to
> be able to rename header files.
You might at least investigate if there is somehow another iconv.h
header besides the system one under /usr/include, that might have been
used by the compiler instead of the standard one from GNU libc.
--
Marco Roeland
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 13:51 14% ` Bill Lear
@ 2007-06-19 13:58 6% ` Johannes Schindelin
2007-06-19 14:13 6% ` David Kastrup
0 siblings, 1 reply; 35+ results
From: Johannes Schindelin @ 2007-06-19 13:58 UTC (permalink / raw)
To: Bill Lear; +Cc: git
Hi,
On Tue, 19 Jun 2007, Bill Lear wrote:
> On Tuesday, June 19, 2007 at 14:00:07 (+0100) Johannes Schindelin writes:
> >
> >On Tue, 19 Jun 2007, Bill Lear wrote:
> >
> >> Also breaks (tar fails) if I do the 'make configure; ./configure'
> >> route.
> >
> >Then there is a test missing in configure.
>
> Here is the particular error:
>
> install git '/opt/git-1.5.2.2/bin'
> make -C templates DESTDIR='' install
> make[1]: Entering directory `/home/blear/build/git-1.5.2.2/templates'
> install -d -m755 '/opt/git-1.5.2.2/share/git-core/templates/'
> (cd blt && gtar cf - .) | \
> (cd '/opt/git-1.5.2.2/share/git-core/templates/' && gtar xf -)
> gtar: This does not look like a tar archive
> gtar: Skipping to next header
> gtar: Archive contains obsolescent base-64 headers
> gtar: Error exit delayed from previous errors
> make[1]: *** [install] Error 2
> make[1]: Leaving directory `/home/blear/build/git-1.5.2.2/templates'
> make: *** [install] Error 2
WTF? gtar cannot read its own output?
Be that as may, this is not git error.
Ciao,
Dscho
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 13:53 6% ` Bill Lear
@ 2007-06-19 13:57 6% ` Johannes Schindelin
0 siblings, 0 replies; 35+ results
From: Johannes Schindelin @ 2007-06-19 13:57 UTC (permalink / raw)
To: Bill Lear; +Cc: git
Hi,
On Tue, 19 Jun 2007, Bill Lear wrote:
> On Tuesday, June 19, 2007 at 14:00:07 (+0100) Johannes Schindelin writes:
> >
> >You are missing libiconv.
>
> Hmm, don't think so:
>
> % ls -l /usr/local/lib/libiconv*
> -rw-r--r-- 1 root root 789 May 14 13:31 /usr/local/lib/libiconv.la
But you do! Unless you say that gcc should also look in /usr/local/lib for
libraries.
Ciao,
Dscho
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 13:00 6% ` Johannes Schindelin
2007-06-19 13:24 6% ` Marco Roeland
2007-06-19 13:51 14% ` Bill Lear
@ 2007-06-19 13:53 6% ` Bill Lear
2007-06-19 13:57 6% ` Johannes Schindelin
2 siblings, 1 reply; 35+ results
From: Bill Lear @ 2007-06-19 13:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
On Tuesday, June 19, 2007 at 14:00:07 (+0100) Johannes Schindelin writes:
>
>You are missing libiconv.
Hmm, don't think so:
% ls -l /usr/local/lib/libiconv*
-rw-r--r-- 1 root root 789 May 14 13:31 /usr/local/lib/libiconv.la
lrwxrwxrwx 1 root root 17 May 14 13:31 /usr/local/lib/libiconv.so -> libiconv.so.2.4.0
lrwxrwxrwx 1 root root 17 May 14 13:31 /usr/local/lib/libiconv.so.2 -> libiconv.so.2.4.0
-rw-r--r-- 1 root root 1234292 May 14 13:31 /usr/local/lib/libiconv.so.2.4.0
Bill
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 13:00 6% ` Johannes Schindelin
2007-06-19 13:24 6% ` Marco Roeland
@ 2007-06-19 13:51 14% ` Bill Lear
2007-06-19 13:58 6% ` Johannes Schindelin
2007-06-19 13:53 6% ` Bill Lear
2 siblings, 1 reply; 35+ results
From: Bill Lear @ 2007-06-19 13:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
On Tuesday, June 19, 2007 at 14:00:07 (+0100) Johannes Schindelin writes:
>Hi,
>
>On Tue, 19 Jun 2007, Bill Lear wrote:
>
>> Also breaks (tar fails) if I do the 'make configure; ./configure'
>> route.
>
>Then there is a test missing in configure.
Here is the particular error:
install git '/opt/git-1.5.2.2/bin'
make -C templates DESTDIR='' install
make[1]: Entering directory `/home/blear/build/git-1.5.2.2/templates'
install -d -m755 '/opt/git-1.5.2.2/share/git-core/templates/'
(cd blt && gtar cf - .) | \
(cd '/opt/git-1.5.2.2/share/git-core/templates/' && gtar xf -)
gtar: This does not look like a tar archive
gtar: Skipping to next header
gtar: Archive contains obsolescent base-64 headers
gtar: Error exit delayed from previous errors
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/blear/build/git-1.5.2.2/templates'
make: *** [install] Error 2
Bill
^ permalink raw reply [relevance 14%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 13:24 6% ` Marco Roeland
@ 2007-06-19 13:50 6% ` Bill Lear
2007-06-19 14:30 6% ` Marco Roeland
0 siblings, 1 reply; 35+ results
From: Bill Lear @ 2007-06-19 13:50 UTC (permalink / raw)
To: Marco Roeland; +Cc: Johannes Schindelin, git
On Tuesday, June 19, 2007 at 15:24:56 (+0200) Marco Roeland writes:
>On Tuesday June 19th 2007 at 14:00 Johannes Schindelin wrote:
>
>> On Tue, 19 Jun 2007, Bill Lear wrote:
>>
>> > Also breaks (tar fails) if I do the 'make configure; ./configure'
>> > route.
>>
>> Then there is a test missing in configure.
>>
>> > /home/blear/build/git-1.5.2.2/utf8.c:328: undefined reference to `libiconv'
>>
>> You are missing libiconv.
>
>On Linux there usually is no separate libiconv as this is integrated
>into GNU libc. Most of the time this kind of error results when somehow
>there _is_ a separate installation of libiconv under /usr/local/lib or
>something. An #include <iconv.h> then finds the version under
>/usr/local/include/iconv.h which has rather different definitions, due to
>using all kind of macros.
>
>If this is Bills situation try uninstalling the separate iconv package
>or at least temporarily rename its iconv.h header.
Well, I'll try that, but this is a fresh install of Centos 5, not a
custom-hacked OS, and I would think that git should build out of the
box on it.
I checked and there is no iconv package (rpm). I really don't want
to have to temporarily rename a header. I can't hand this out to
the rest of the company, some of whom do not have root access to
be able to rename header files.
Bill
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 13:00 6% ` Johannes Schindelin
@ 2007-06-19 13:24 6% ` Marco Roeland
2007-06-19 13:50 6% ` Bill Lear
2007-06-19 13:51 14% ` Bill Lear
2007-06-19 13:53 6% ` Bill Lear
2 siblings, 1 reply; 35+ results
From: Marco Roeland @ 2007-06-19 13:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, git
On Tuesday June 19th 2007 at 14:00 Johannes Schindelin wrote:
> On Tue, 19 Jun 2007, Bill Lear wrote:
>
> > Also breaks (tar fails) if I do the 'make configure; ./configure'
> > route.
>
> Then there is a test missing in configure.
>
> > /home/blear/build/git-1.5.2.2/utf8.c:328: undefined reference to `libiconv'
>
> You are missing libiconv.
On Linux there usually is no separate libiconv as this is integrated
into GNU libc. Most of the time this kind of error results when somehow
there _is_ a separate installation of libiconv under /usr/local/lib or
something. An #include <iconv.h> then finds the version under
/usr/local/include/iconv.h which has rather different definitions, due to
using all kind of macros.
If this is Bills situation try uninstalling the separate iconv package
or at least temporarily rename its iconv.h header.
--
Marco Roeland
^ permalink raw reply [relevance 6%]
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
2007-06-19 12:37 12% Errors building git-1.5.2.2 on 64-bit Centos 5 Bill Lear
@ 2007-06-19 13:00 6% ` Johannes Schindelin
2007-06-19 13:24 6% ` Marco Roeland
` (2 more replies)
0 siblings, 3 replies; 35+ results
From: Johannes Schindelin @ 2007-06-19 13:00 UTC (permalink / raw)
To: Bill Lear; +Cc: git
Hi,
On Tue, 19 Jun 2007, Bill Lear wrote:
> Also breaks (tar fails) if I do the 'make configure; ./configure'
> route.
Then there is a test missing in configure.
> /home/blear/build/git-1.5.2.2/utf8.c:328: undefined reference to `libiconv'
You are missing libiconv.
Ciao,
Dscho
^ permalink raw reply [relevance 6%]
* Errors building git-1.5.2.2 on 64-bit Centos 5
@ 2007-06-19 12:37 12% Bill Lear
2007-06-19 13:00 6% ` Johannes Schindelin
0 siblings, 1 reply; 35+ results
From: Bill Lear @ 2007-06-19 12:37 UTC (permalink / raw)
To: git
Also breaks (tar fails) if I do the 'make configure; ./configure'
route. This is my third try to send this. I sent also to Junio
yesterday, but no response.
% uname -a Linux blake 2.6.18-8.1.4.el5xen #1 SMP Thu May 17 03:43:13 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
% gcc --version
gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-52)
% make prefix=/opt/git-1.5.2.2 all doc
GIT_VERSION = 1.5.2.2-dirty
* new build flags or prefix
CC convert-objects.o
CC blob.o
CC commit.o
CC connect.o
CC csum-file.o
CC cache-tree.o
CC base85.o
CC date.o
CC diff-delta.o
CC entry.o
CC exec_cmd.o
CC ident.o
CC interpolate.o
CC lockfile.o
CC patch-ids.o
CC object.o
CC pack-check.o
CC pack-write.o
CC patch-delta.o
CC path.o
CC pkt-line.o
CC sideband.o
CC reachable.o
CC reflog-walk.o
CC quote.o
CC read-cache.o
CC refs.o
CC run-command.o
CC dir.o
CC object-refs.o
CC server-info.o
CC setup.o
CC sha1_file.o
CC sha1_name.o
CC strbuf.o
CC tag.o
CC tree.o
CC usage.o
CC config.o
CC environment.o
CC ctype.o
CC copy.o
CC revision.o
CC pager.o
CC tree-walk.o
CC xdiff-interface.o
CC write_or_die.o
CC trace.o
CC list-objects.o
CC grep.o
CC match-trees.o
CC alloc.o
CC merge-file.o
CC path-list.o
GEN common-cmds.h
CC help.o
CC unpack-trees.o
CC diff.o
CC diff-lib.o
CC diffcore-break.o
CC diffcore-order.o
CC diffcore-pickaxe.o
CC diffcore-rename.o
CC tree-diff.o
CC combine-diff.o
CC diffcore-delta.o
CC log-tree.o
CC color.o
CC wt-status.o
CC archive-zip.o
CC archive-tar.o
CC shallow.o
CC utf8.o
CC convert.o
CC attr.o
CC decorate.o
CC progress.o
CC mailmap.o
CC symlinks.o
CC compat/strlcpy.o
AR libgit.a
CC xdiff/xdiffi.o
CC xdiff/xprepare.o
CC xdiff/xutils.o
CC xdiff/xemit.o
CC xdiff/xmerge.o
AR xdiff/lib.a
LINK git-convert-objects
libgit.a(utf8.o): In function `reencode_string':
/home/blear/build/git-1.5.2.2/utf8.c:317: undefined reference to `libiconv_open'
/home/blear/build/git-1.5.2.2/utf8.c:328: undefined reference to `libiconv'
/home/blear/build/git-1.5.2.2/utf8.c:353: undefined reference to `libiconv_close'
/home/blear/build/git-1.5.2.2/utf8.c:334: undefined reference to `libiconv_close'
collect2: ld returned 1 exit status
make: *** [git-convert-objects] Error 1
Bill
^ permalink raw reply [relevance 12%]
* Re: [ANNOUNCE] GIT 1.5.2.2
2007-06-18 6:29 6% ` Shawn O. Pearce
@ 2007-06-18 6:35 6% ` Arkadiusz Miskiewicz
0 siblings, 0 replies; 35+ results
From: Arkadiusz Miskiewicz @ 2007-06-18 6:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
On Monday 18 of June 2007, Shawn O. Pearce wrote:
> Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> > On Monday 18 of June 2007, Shawn O. Pearce wrote:
> > > Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> > > > * FAIL 16: corrupt a pack and see if verify catches
> > > > cat test-1-${packname_1}.idx >test-3.idx &&
> > > > cat test-2-${packname_2}.pack >test-3.pack &&
> > >
> > > Hmm. That is t5300-pack-objects.sh.
> >
> > If anyone is interested in debugging that problem then I can give ssh
> > access to this machine.
>
> How about we start with the output of:
>
> cd t && ./t5300-pack-objects.sh -v
>
> ? That should be a lot more verbose, as it will include the
> commands we are running and their stdout/stderr. Sometimes fun
> details about broken tools can be easily obtained from that output.
The reason was... missing /dev/zero! :-) Mystery solved, thanks!
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply [relevance 6%]
* Re: [ANNOUNCE] GIT 1.5.2.2
2007-06-18 6:21 6% ` Arkadiusz Miskiewicz
@ 2007-06-18 6:29 6% ` Shawn O. Pearce
2007-06-18 6:35 6% ` Arkadiusz Miskiewicz
0 siblings, 1 reply; 35+ results
From: Shawn O. Pearce @ 2007-06-18 6:29 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: Junio C Hamano, git
Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> On Monday 18 of June 2007, Shawn O. Pearce wrote:
> > Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> > > * FAIL 16: corrupt a pack and see if verify catches
> > > cat test-1-${packname_1}.idx >test-3.idx &&
> > > cat test-2-${packname_2}.pack >test-3.pack &&
> >
> > Hmm. That is t5300-pack-objects.sh.
>
> If anyone is interested in debugging that problem then I can give ssh access
> to this machine.
How about we start with the output of:
cd t && ./t5300-pack-objects.sh -v
? That should be a lot more verbose, as it will include the
commands we are running and their stdout/stderr. Sometimes fun
details about broken tools can be easily obtained from that output.
--
Shawn.
^ permalink raw reply [relevance 6%]
* Re: [ANNOUNCE] GIT 1.5.2.2
2007-06-18 3:43 5% ` Shawn O. Pearce
@ 2007-06-18 6:21 6% ` Arkadiusz Miskiewicz
2007-06-18 6:29 6% ` Shawn O. Pearce
0 siblings, 1 reply; 35+ results
From: Arkadiusz Miskiewicz @ 2007-06-18 6:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
On Monday 18 of June 2007, Shawn O. Pearce wrote:
> Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> > On Sunday 17 of June 2007, Junio C Hamano wrote:
> > > The latest maintenance release GIT 1.5.2.2 is available at the
> > > usual places:
[...]
> > Should git testsuite (make test) go without any problem? (I'm asking
> > because some projects have test suites where some tests are expected to
> > fail).
>
[...]
>
> > * FAIL 16: corrupt a pack and see if verify catches
> > cat test-1-${packname_1}.idx >test-3.idx &&
> > cat test-2-${packname_2}.pack >test-3.pack &&
>
> Hmm. That is t5300-pack-objects.sh. Something is really fishy
> if that test failed. We destroy a packfile and then look to see
> if the SHA-1 hash detects the change. It always does. So uh,
> what's up with your hardware that it doesn't fail?
There is no problems known with this hardware (kernel builds are frequently
done on it and no problem occured so far). Test suite fails in the same place
each time I'm running it.
> I just built 1.5.2.2 on one of my Gentoo Linux amd64 systems and I'm
> not seeing any failures from the test suite. Not that I expected
> to find any; Linux amd64 is popular enough that a number of people
> run it.
Not all have the same enviroment.
coreutils-6.9-2.x86_64
curl-7.16.2-1.x86_64
diffutils-2.8.7-4.x86_64
expat-2.0.0-3.x86_64
findutils-4.2.31-1.x86_64
gcc-4.2.0-6.x86_64
glibc-2.6-1.i686
glibc-2.6-1.x86_64
grep-2.5.1a-2.x86_64
openssl-0.9.8e-4.x86_64
perl-5.8.8-11.x86_64
python-2.5.1-2.x86_64
sed-4.1.5-2.x86_64
zlib-1.2.3-4.x86_64
If anyone is interested in debugging that problem then I can give ssh access
to this machine.
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply [relevance 6%]
* Re: [ANNOUNCE] GIT 1.5.2.2
2007-06-17 10:30 5% ` Arkadiusz Miskiewicz
@ 2007-06-18 3:43 5% ` Shawn O. Pearce
2007-06-18 6:21 6% ` Arkadiusz Miskiewicz
0 siblings, 1 reply; 35+ results
From: Shawn O. Pearce @ 2007-06-18 3:43 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: Junio C Hamano, git
Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> On Sunday 17 of June 2007, Junio C Hamano wrote:
> > The latest maintenance release GIT 1.5.2.2 is available at the
> > usual places:
> >
> > http://www.kernel.org/pub/software/scm/git/
> >
> > git-1.5.2.2.tar.{gz,bz2} (tarball)
> > git-htmldocs-1.5.2.2.tar.{gz,bz2} (preformatted docs)
> > git-manpages-1.5.2.2.tar.{gz,bz2} (preformatted docs)
> > RPMS/$arch/git-*-1.5.2.2-1.$arch.rpm (RPM)
>
> Should git testsuite (make test) go without any problem? (I'm asking because
> some projects have test suites where some tests are expected to fail).
No, our test suite should always pass. Junio does not ship a release
of Git where the test suite fails on his standard systems. We have
a lot of users running the current `master` and `next` branches on
a lot of different platforms, so usually platform specific breakages
are caught relatively early, before a release gets made.
We do have tests we expect to fail, but then the test suite has an
inversion in it. That is the test only passes if the underlying
operation failed. ;-)
> I have 4 failures on amd64/linux and this git release:
...
> * FAIL 16: corrupt a pack and see if verify catches
> cat test-1-${packname_1}.idx >test-3.idx &&
> cat test-2-${packname_2}.pack >test-3.pack &&
Hmm. That is t5300-pack-objects.sh. Something is really fishy
if that test failed. We destroy a packfile and then look to see
if the SHA-1 hash detects the change. It always does. So uh,
what's up with your hardware that it doesn't fail?
I just built 1.5.2.2 on one of my Gentoo Linux amd64 systems and I'm
not seeing any failures from the test suite. Not that I expected
to find any; Linux amd64 is popular enough that a number of people
run it.
--
Shawn.
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.5.2.2
2007-06-17 1:57 10% [ANNOUNCE] GIT 1.5.2.2 Junio C Hamano
2007-06-17 10:30 5% ` Arkadiusz Miskiewicz
@ 2007-06-18 3:27 6% ` Shawn O. Pearce
2007-06-20 8:34 6% ` Jakub Narebski
2 siblings, 0 replies; 35+ results
From: Shawn O. Pearce @ 2007-06-18 3:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
Junio C Hamano <gitster@pobox.com> wrote:
> GIT v1.5.2.2 Release Notes
> ==========================
>
> Fixes since v1.5.2.1
> --------------------
>
> * Usability fix
>
> - git-gui is shipped with its updated blame interface. It is
> rumored that the older one was not just unusable but was
> active health hazard, but this one is actually pretty.
> Please see for yourself.
Usability fix? More like finally implemented! _Now_ we can start
to work on improving its usability. ;-)
--
Shawn.
^ permalink raw reply [relevance 6%]
* Re: [ANNOUNCE] GIT 1.5.2.2
2007-06-17 1:57 10% [ANNOUNCE] GIT 1.5.2.2 Junio C Hamano
@ 2007-06-17 10:30 5% ` Arkadiusz Miskiewicz
2007-06-18 3:43 5% ` Shawn O. Pearce
2007-06-18 3:27 6% ` Shawn O. Pearce
2007-06-20 8:34 6% ` Jakub Narebski
2 siblings, 1 reply; 35+ results
From: Arkadiusz Miskiewicz @ 2007-06-17 10:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sunday 17 of June 2007, Junio C Hamano wrote:
> The latest maintenance release GIT 1.5.2.2 is available at the
> usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.5.2.2.tar.{gz,bz2} (tarball)
> git-htmldocs-1.5.2.2.tar.{gz,bz2} (preformatted docs)
> git-manpages-1.5.2.2.tar.{gz,bz2} (preformatted docs)
> RPMS/$arch/git-*-1.5.2.2-1.$arch.rpm (RPM)
Should git testsuite (make test) go without any problem? (I'm asking because
some projects have test suites where some tests are expected to fail).
I have 4 failures on amd64/linux and this git release:
* FAIL 11: compare delta flavors
perl -e '
defined($_ = -s $_) or die for @ARGV;
exit 1 if $ARGV[0] <= $ARGV[1];
' test-2-$packname_2.pack test-3-$packname_3.pack
[...]
* FAIL 16: corrupt a pack and see if verify catches
cat test-1-${packname_1}.idx >test-3.idx &&
cat test-2-${packname_2}.pack >test-3.pack &&
if git-verify-pack test-3.idx
then false
else :;
fi &&
: PACK_SIGNATURE &&
cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=2
&&
if git-verify-pack test-3.idx
then false
else :;
fi &&
: PACK_VERSION &&
cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=7
&&
if git-verify-pack test-3.idx
then false
else :;
fi &&
: TYPE/SIZE byte of the first packed object data &&
cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=12
&&
if git-verify-pack test-3.idx
then false
else :;
fi &&
: sum of the index file itself &&
l=`wc -c <test-3.idx` &&
l=`expr $l - 20` &&
cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.idx count=20 bs=1 conv=notrunc seek=$l
&&
if git-verify-pack test-3.pack
then false
else :;
fi &&
:
[...]
* FAIL 18: fake a SHA1 hash collision
test -f .git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67 &&
cp -f .git/objects/9d/235ed07cd19811a6ceb342de82f190e49c9f68
\
.git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67
* FAIL 19: make sure index-pack detects the SHA1 collision
git-index-pack -o bad.idx test-3.pack
* failed 4 among 19 test(s)
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply [relevance 5%]
* [ANNOUNCE] GIT 1.5.2.2
@ 2007-06-17 1:57 10% Junio C Hamano
2007-06-17 10:30 5% ` Arkadiusz Miskiewicz
` (2 more replies)
0 siblings, 3 replies; 35+ results
From: Junio C Hamano @ 2007-06-17 1:57 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.5.2.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.2.2.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.2.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.2.2.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.2.2-1.$arch.rpm (RPM)
GIT v1.5.2.2 Release Notes
==========================
Fixes since v1.5.2.1
--------------------
* Usability fix
- git-gui is shipped with its updated blame interface. It is
rumored that the older one was not just unusable but was
active health hazard, but this one is actually pretty.
Please see for yourself.
* Bugfixes
- "git checkout fubar" was utterly confused when there is a
branch fubar and a tag fubar at the same time. It correctly
checks out the branch fubar now.
- "git clone /path/foo" to clone a local /path/foo.git
repository left an incorrect configuration.
- "git send-email" correctly unquotes RFC 2047 quoted names in
the patch-email before using their values.
- We did not accept number of seconds since epoch older than
year 2000 as a valid timestamp. We now interpret positive
integers more than 8 digits as such, which allows us to
express timestamps more recent than March 1973.
- git-cvsimport did not work when you have GIT_DIR to point
your repository at a nonstandard location.
- Some systems (notably, Solaris) lack hstrerror() to make
h_errno human readable; prepare a replacement
implementation.
- .gitignore file listed git-core.spec but what we generate is
git.spec, and nobody noticed for a long time.
- "git-merge-recursive" does not try to run file level merge
on binary files.
- "git-branch --track" did not create tracking configuration
correctly when the branch name had slash in it.
- The email address of the user specified with user.email
configuration was overriden by EMAIL environment variable.
- The tree parser did not warn about tree entries with
nonsense file modes, and assumed they must be blobs.
- "git log -z" without any other request to generate diff still
invoked the diff machinery, wasting cycles.
* Documentation
- Many updates to fix stale or missing documentation.
- Although our documentation was primarily meant to be formatted
with AsciiDoc7, formatting with AsciiDoc8 is supported better.
----------------------------------------------------------------
Changes since v1.5.2.1 are as follows:
Alex Riesen (3):
Make the installation target of git-gui a little less chatty
Fix clone to setup the origin if its name ends with .git
Add a local implementation of hstrerror for the system which do not have it
Gerrit Pape (1):
Fix typo in remote branch example in git user manual
J. Bruce Fields (4):
user-manual: quick-start updates
user-manual: add a missing section ID
Documentation: user-manual todo
tutorial: use "project history" instead of "changelog" in header
Jakub Narebski (1):
Generated spec file to be ignored is named git.spec and not git-core.spec
Johannes Schindelin (2):
Move buffer_is_binary() to xdiff-interface.h
merge-recursive: refuse to merge binary files
Johannes Sixt (1):
Accept dates before 2000/01/01 when specified as seconds since the epoch
Junio C Hamano (6):
checkout: do not get confused with ambiguous tag/branch names
$EMAIL is a last resort fallback, as it's system-wide.
git-branch --track: fix tracking branch computation.
Avoid diff cost on "git log -z"
Documentation: adjust to AsciiDoc 8
GIT 1.5.2.2
Kristian H淡gsberg (1):
Unquote From line from patch before comparing with given from address.
Luiz Fernando N. Capitulino (1):
git-cherry: Document 'limit' command-line option
Matthijs Melchior (1):
New selection indication and softer colors
Michael Milligan (1):
git-cvsimport: Make sure to use $git_dir always instead of .git sometimes
Sam Vilain (2):
fix documentation of unpack-objects -n
Don't assume tree entries that are not dirs are blobs
Shawn O. Pearce (47):
git-gui: Allow creating a branch when none exists
git-gui: Allow as few as 0 lines of diff context
git-gui: Don't quit when we destroy a child widget
git-gui: Attach font_ui to all spinbox widgets
git-gui: Verify Tcl/Tk is new enough for our needs
Revert "Make the installation target of git-gui a little less chatty"
git-gui: Add a 4 digit commit abbreviation to the blame viewer
git-gui: Cleanup blame::new widget initialization
git-gui: Remove empty blank line at end of blame
git-gui: Improve the coloring in blame viewer
git-gui: Simplify consecutive lines that come from the same commit
git-gui: Use arror cursor in blame viewer file data
git-gui: Display tooltips in blame viewer
git-gui: Highlight the blame commit header from everything else
git-gui: Remove unnecessary reshow of blamed commit
git-gui: Cleanup minor style nit
git-gui: Space the commit group continuation out in blame view
git-gui: Show author initials in blame groups
git-gui: Allow the user to control the blame/commit split point
git-gui: Display a progress bar during blame annotation gathering
git-gui: Allow digging through history in blame viewer
git-gui: Combine blame groups only if commit and filename match
git-gui: Show original filename in blame tooltip
git-gui: Use a label instead of a button for the back button
git-gui: Clip the commit summaries in the blame history menu
git-gui: Remove the loaded column from the blame viewer
git-gui: Remove unnecessary space between columns in blame viewer
git-gui: Use lighter colors in blame view
git-gui: Make the line number column slightly wider in blame
git-gui: Automatically expand the line number column as needed
git-gui: Remove unused commit_list from blame viewer
git-gui: Better document our blame variables
git-gui: Cleanup redundant column management in blame viewer
git-gui: Switch internal blame structure to Tcl lists
git-gui: Label the uncommitted blame history entry
git-gui: Rename fields in blame viewer to better descriptions
git-gui: Display the "Loading annotation..." message in italic
git-gui: Run blame twice on the same file and display both outputs
git-gui: Display both commits in our tooltips
git-gui: Jump to original line in blame viewer
git-gui: Use three colors for the blame viewer background
git-gui: Improve our labeling of blame annotation types
git-gui: Favor the original annotations over the recent ones
git-gui: Changed blame header bar background to match main window
git-gui: Include 'war on whitespace' fixes from git.git
git-gui: Give amend precedence to HEAD over MERGE_MSG
git-gui: Save geometry before the window layout is damaged
william pursell (1):
Make command description imperative statement, not third-person present.
^ permalink raw reply [relevance 10%]
Results 1-35 of 35 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2007-05-13 22:30 What's in git.git (stable) Junio C Hamano
2007-05-17 0:21 ` Junio C Hamano
2007-05-19 5:24 ` Junio C Hamano
2007-05-23 21:46 ` Junio C Hamano
2007-05-29 10:12 ` Junio C Hamano
2007-06-02 21:09 ` Junio C Hamano
2007-06-07 2:08 ` Junio C Hamano
2007-06-13 20:11 ` Junio C Hamano
2007-06-21 7:21 6% ` Junio C Hamano
2007-06-17 1:57 10% [ANNOUNCE] GIT 1.5.2.2 Junio C Hamano
2007-06-17 10:30 5% ` Arkadiusz Miskiewicz
2007-06-18 3:43 5% ` Shawn O. Pearce
2007-06-18 6:21 6% ` Arkadiusz Miskiewicz
2007-06-18 6:29 6% ` Shawn O. Pearce
2007-06-18 6:35 6% ` Arkadiusz Miskiewicz
2007-06-18 3:27 6% ` Shawn O. Pearce
2007-06-20 8:34 6% ` Jakub Narebski
2007-06-19 12:37 12% Errors building git-1.5.2.2 on 64-bit Centos 5 Bill Lear
2007-06-19 13:00 6% ` Johannes Schindelin
2007-06-19 13:24 6% ` Marco Roeland
2007-06-19 13:50 6% ` Bill Lear
2007-06-19 14:30 6% ` Marco Roeland
2007-06-19 14:48 13% ` Bill Lear
2007-06-19 15:12 6% ` David Kastrup
2007-06-19 16:16 12% ` Bill Lear
2007-06-19 20:09 6% ` Alex Riesen
2007-06-19 20:57 3% ` Bill Lear
2007-06-19 21:11 6% ` Johannes Schindelin
2007-06-19 21:11 6% ` Junio C Hamano
2007-06-19 21:17 6% ` Bill Lear
2007-06-19 13:51 14% ` Bill Lear
2007-06-19 13:58 6% ` Johannes Schindelin
2007-06-19 14:13 6% ` David Kastrup
2007-06-19 13:53 6% ` Bill Lear
2007-06-19 13:57 6% ` Johannes Schindelin
2007-06-20 2:45 5% Errors install git-1.5.2.2 on 64-bit AIX Dongsheng Song
2007-06-20 3:21 6% ` Linus Torvalds
2007-06-20 3:36 6% ` Dongsheng Song
2007-07-03 19:02 6% gitk doesn't start due to cygwin wish not following symlinks? Kees-Jan Dijkzeul
2007-07-06 9:33 5% ` Jan Hudec
2007-07-11 12:59 cg switch -l doesn't work when branches point to the same commit Bradford Smith
2007-07-11 13:36 5% ` Alex Riesen
2007-08-07 9:02 6% git on Cygwin: Not a valid object name HEAD Sebastian Schuberth
2008-07-14 7:50 Closing the merge window for 1.6.0 Junio C Hamano
2008-07-14 8:55 ` Petr Baudis
2008-07-14 11:57 ` Johannes Schindelin
2008-07-14 12:41 ` Gerrit Pape
2008-07-14 17:54 ` Nicolas Pitre
2008-07-14 19:00 ` Junio C Hamano
2008-07-15 9:20 ` Petr Baudis
2008-07-15 15:06 ` Dmitry Potapov
2008-07-15 15:27 ` Johannes Schindelin
2008-07-15 16:26 ` Nicolas Pitre
2008-07-15 17:28 4% ` Petr Baudis
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).