* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: David Kastrup @ 2007-06-19 14:13 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706191457440.4059@racer.site>
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
* Re: git-gui cannot find share/git-gui under cygwin
From: Shawn O. Pearce @ 2007-06-19 14:49 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List
In-Reply-To: <4677CBD7.9050606@gmail.com>
Mark Levedahl <mlevedahl@gmail.com> wrote:
> Commit ea75ee3598ab6f8d0828f introduced logic to guess where
> share/git-gui/lib is at runtime, and this is broken on Cygwin. The basic
> problem is that:
>
> /usr/bin = c:\cygwin\bin
> /usr/share = c:\cygwin\usr\share
>
> The detection logic correctly finds the wish binary in c:\cygwin\bin,
> and then assumes that the share directory is c:\cygwin\share rather than
> c:\cygwin\usr\share. Given this, git-gui does not load as it cannot find
> its share/git-gui/lib directory
Yuck. I'm considering applying the following. It works ok on Mac
OS X where the bug isn't triggered anyway. ;-) I won't be able to
test on Cygwin until tomorrow.
-->8--
git-gui: Correctly install to /usr/bin on Cygwin
Mark Levedahl <mlevedahl@gmail.com> noted that installation on Cygwin
to /usr/bin can cause problems with the automatic guessing of our
library location. The problem is that installation to /usr/bin
means we actually have:
/usr/bin = c:\cygwin\bin
/usr/share = c:\cygwin\usr\share
So git-gui guesses that its library should be found within the
c:\cygwin\share directory, as that is where it should be relative
to the script itself in c:\cygwin\bin.
In this case we have to use `cygpath` during installation to find out
what the mapping is from the UNIX path we are seeing in GNU make,
to the Windows path we will actually see in our Tcl/Tk process.
After that mapping has been performed we can then test to see if
our share directory can be found by relative location, or if we
need to encode the absolute location.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Makefile | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 3de0de1..1c01c83 100644
--- a/Makefile
+++ b/Makefile
@@ -7,6 +7,8 @@ GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
+uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
+
SCRIPT_SH = git-gui.sh
GITGUI_BUILT_INS = git-citool
ALL_PROGRAMS = $(GITGUI_BUILT_INS) $(patsubst %.sh,%,$(SCRIPT_SH))
@@ -58,14 +60,22 @@ exedir_SQ = $(subst ','\'',$(exedir))
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
$(QUIET_GEN)rm -f $@ $@+ && \
- if test '$(exedir_SQ)' = '$(libdir_SQ)'; then \
+ A='$(exedir_SQ)' && \
+ B='$(libdir_SQ)' && \
+ if test "$(uname_O)" = Cygwin; then \
+ A="$$(cygpath -m -a "$$A")" && \
+ B="$$(cygpath -m -a "$$B")"; \
+ fi && \
+ if test "$$A" = "$$B"; then \
GITGUI_RELATIVE=1; \
+ else \
+ GITGUI_RELATIVE=; \
fi && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's|^exec wish "$$0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$0"|' \
-e 's/@@GITGUI_VERSION@@/$(GITGUI_VERSION)/g' \
-e 's|@@GITGUI_RELATIVE@@|'$$GITGUI_RELATIVE'|' \
- -e $$GITGUI_RELATIVE's|@@GITGUI_LIBDIR@@|$(libdir_SQ)|' \
+ -e $$GITGUI_RELATIVE"s|@@GITGUI_LIBDIR@@|$$B|" \
$@.sh >$@+ && \
chmod +x $@+ && \
mv $@+ $@
--
1.5.2.2.1012.ge05f4
--
Shawn.
^ permalink raw reply related
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Bill Lear @ 2007-06-19 14:48 UTC (permalink / raw)
To: Marco Roeland; +Cc: Johannes Schindelin, git
In-Reply-To: <20070619143000.GA15352@fiberbit.xs4all.nl>
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
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Marco Roeland @ 2007-06-19 14:30 UTC (permalink / raw)
To: Bill Lear; +Cc: Johannes Schindelin, git
In-Reply-To: <18039.57099.57602.28299@lisa.zopyra.com>
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
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Johannes Schindelin @ 2007-06-19 13:58 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18039.57163.667319.439210@lisa.zopyra.com>
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
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Johannes Schindelin @ 2007-06-19 13:57 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18039.57290.14570.879740@lisa.zopyra.com>
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
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Bill Lear @ 2007-06-19 13:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706191359160.4059@racer.site>
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
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Bill Lear @ 2007-06-19 13:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706191359160.4059@racer.site>
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
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Bill Lear @ 2007-06-19 13:50 UTC (permalink / raw)
To: Marco Roeland; +Cc: Johannes Schindelin, git
In-Reply-To: <20070619132456.GA15023@fiberbit.xs4all.nl>
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
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Marco Roeland @ 2007-06-19 13:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, git
In-Reply-To: <Pine.LNX.4.64.0706191359160.4059@racer.site>
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
* Re: Errors building git-1.5.2.2 on 64-bit Centos 5
From: Johannes Schindelin @ 2007-06-19 13:00 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18039.52754.563688.907038@lisa.zopyra.com>
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
* Re: [ANNOUNCE] tig 0.8
From: Jonas Fonseca @ 2007-06-19 12:41 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86zm2wmbmu.fsf@blue.stonehenge.com>
Randal L. Schwartz <merlyn@stonehenge.com> wrote Tue, Jun 19, 2007:
> [...] an affect announcement of "tig" (even an update release) should probably
> include at least one sentence of what it is, so I can decide whether to be
> interested or ignore it.
Yeah, you are right. I got the hint from a cgit release not so long ago
that was also "blamed" for lacking a small project introduction. I was
in a hurry and forgot all about it this morning ...
--
Jonas Fonseca
^ permalink raw reply
* Errors building git-1.5.2.2 on 64-bit Centos 5
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
* git-gui cannot find share/git-gui under cygwin
From: Mark Levedahl @ 2007-06-19 12:28 UTC (permalink / raw)
To: Shawn O. Pearce, Git Mailing List
Commit ea75ee3598ab6f8d0828f introduced logic to guess where
share/git-gui/lib is at runtime, and this is broken on Cygwin. The basic
problem is that:
/usr/bin = c:\cygwin\bin
/usr/share = c:\cygwin\usr\share
The detection logic correctly finds the wish binary in c:\cygwin\bin,
and then assumes that the share directory is c:\cygwin\share rather than
c:\cygwin\usr\share. Given this, git-gui does not load as it cannot find
its share/git-gui/lib directory
Mark Levedahl
^ permalink raw reply
* Re: builtin-fetch code with messy history
From: Alex Riesen @ 2007-06-19 11:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706191249480.4059@racer.site>
On 6/19/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On 6/19/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > >
> > > > > Maybe this is the right time to cut off branches/* and remotes/*?
> > > >
> > > > Seconded. Don't use the remotes/ since some months now.
> > > > But... isn't a git package with code of something like 1.4.4 is still
> > > > in some major distributions?
> > >
> > > Yes, AFAICT it is Ubuntu "the most up-to-date distro there is". At least
> > > many questions on the list and in IRC suggest that.
> > >
> > > So, how about checking (at least for a year) in builtin-fetch, if
> > > "branches/" or "remotes/" exist, and fail, with a nice message how to move
> > > to config-based remotes?
> >
> > ...by suggesting to use a nice conversion script which we don't
> > have.
>
> git.git/contrib/remotes2config.sh
>
> IIRC it was explicitely asked to leave branches/* out of that script, but
> the original version had it, and it should be easy to include it again.
Right, missed it. Sounds like we have a plan
^ permalink raw reply
* Re: builtin-fetch code with messy history
From: Johannes Schindelin @ 2007-06-19 11:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: Daniel Barkalow, git, Junio C Hamano
In-Reply-To: <81b0412b0706190447y37c3aedbya42b7a3d5703322c@mail.gmail.com>
Hi,
On Tue, 19 Jun 2007, Alex Riesen wrote:
> On 6/19/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > >
> > > > Maybe this is the right time to cut off branches/* and remotes/*?
> > >
> > > Seconded. Don't use the remotes/ since some months now.
> > > But... isn't a git package with code of something like 1.4.4 is still
> > > in some major distributions?
> >
> > Yes, AFAICT it is Ubuntu "the most up-to-date distro there is". At least
> > many questions on the list and in IRC suggest that.
> >
> > So, how about checking (at least for a year) in builtin-fetch, if
> > "branches/" or "remotes/" exist, and fail, with a nice message how to move
> > to config-based remotes?
>
> ...by suggesting to use a nice conversion script which we don't
> have.
git.git/contrib/remotes2config.sh
IIRC it was explicitely asked to leave branches/* out of that script, but
the original version had it, and it should be easy to include it again.
> BTW, as far as I can see, git-remote reads old configuration just fine,
> so it probably will a very simple script: read all and write all. Well,
> the "all" part of it can be a bit complicated, but aside from that...
Ciao,
Dscho
^ permalink raw reply
* [PATCH] new-workdir: handle rev-parse --git-dir not always giving full path
From: Julian Phillips @ 2007-06-19 11:44 UTC (permalink / raw)
To: git
rev-parse --git-dir outputs a full path - except for the single case
of when the path would be $(pwd)/.git, in which case it outputs simply
.git. Check for this special case and handle it.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
I tried to use new-workdir yesterday for the first time in a while, and found that it worked provided I gave a path inside the base repo, but not the path of the repo itself.
Turns out to be an oddity in rev-parse --git-dir output. Since the rev-parse code explicitly does something different, I assume there is a reason for it.
contrib/workdir/git-new-workdir | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/contrib/workdir/git-new-workdir b/contrib/workdir/git-new-workdir
index f2a3615..709b2a3 100755
--- a/contrib/workdir/git-new-workdir
+++ b/contrib/workdir/git-new-workdir
@@ -24,6 +24,11 @@ git_dir=$(cd "$orig_git" 2>/dev/null &&
git rev-parse --git-dir 2>/dev/null) ||
die "\"$orig_git\" is not a git repository!"
+if test "$git_dir" == ".git"
+then
+ git_dir="$orig_git/.git"
+fi
+
# don't link to a workdir
if test -L "$git_dir/config"
then
--
1.5.2.2
^ permalink raw reply related
* Re: builtin-fetch code with messy history
From: Alex Riesen @ 2007-06-19 11:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706191210020.4059@racer.site>
On 6/19/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > Maybe this is the right time to cut off branches/* and remotes/*?
> >
> > Seconded. Don't use the remotes/ since some months now.
> > But... isn't a git package with code of something like 1.4.4 is still
> > in some major distributions?
>
> Yes, AFAICT it is Ubuntu "the most up-to-date distro there is". At least
> many questions on the list and in IRC suggest that.
>
> So, how about checking (at least for a year) in builtin-fetch, if
> "branches/" or "remotes/" exist, and fail, with a nice message how to move
> to config-based remotes?
...by suggesting to use a nice conversion script which we don't
have.
BTW, as far as I can see, git-remote reads old configuration just fine,
so it probably will a very simple script: read all and write all. Well,
the "all" part of it can be a bit complicated, but aside from that...
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: David Kastrup @ 2007-06-19 11:19 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706191208300.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 19 Jun 2007, Frank Lichtenheld wrote:
>
>> On Mon, Jun 18, 2007 at 06:37:35PM -0700, Junio C Hamano wrote:
>> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > Another possibility, though, is to say:
>> >
>> > core.some\0where\0core.over\0\0core.the\0core.rainbow\0
>>
>> How do you denote empty values then?
>>
>> [section]
>> key=
>> key
>>
>> this are two very different statements atm (e.g. the one is false and
>> the other one is true).
>>
>> I still think using two different delimiters is the simplest choice.
>
> Okay, good point. But of course, you have to use a delimiter for the key
> name that cannot be part of the keyname. You picked '\n'. The original was
> '='. Both work.
In the interest of simplicity, it would appear reasonable to use just
= and not introduce an additional delimiter. This is similar to how
environments are handled and passed in Unix (though not necessarily
relevant).
--
David Kastrup
^ permalink raw reply
* Re: [ANNOUNCE] tig 0.8
From: Randal L. Schwartz @ 2007-06-19 11:23 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20070619075731.GA12441@diku.dk>
>>>>> "Jonas" == Jonas Fonseca <fonseca@diku.dk> writes:
Jonas> A new version of tig has been released. It mainly contains bugfixes,
Jonas> most importantly for regressions in the pager mode.
I know you know what tig is. I know *I* could figure out what
tig is by going through the mailing list, or by pulling down the
entire distro from the following:
Jonas> Get the tarball at http://jonas.nitro.dk/tig/releases/
Jonas> or pull it from git://repo.or.cz/tig.git
But an affect announcement of "tig" (even an update release) should probably
include at least one sentence of what it is, so I can decide whether to be
interested or ignore it. My default is ignore it.
Since you have boilerplace for this, you can fix this once, and not worry
about it after that. :)
I'm saying this publicly so that other announcements might also be improved,
not that I've previously noticed any other confusion.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: builtin-fetch code with messy history
From: Johannes Schindelin @ 2007-06-19 11:11 UTC (permalink / raw)
To: Alex Riesen; +Cc: Daniel Barkalow, git, Junio C Hamano
In-Reply-To: <81b0412b0706190313g74765babk38309dd838f3f585@mail.gmail.com>
Hi,
On Tue, 19 Jun 2007, Alex Riesen wrote:
> On 6/19/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > * when a branch config file section refers to a branches/* remote, the
> > > merge setting is used (if one is given), even though this isn't useful
> > > either way.
> >
> > Maybe this is the right time to cut off branches/* and remotes/*?
>
> Seconded. Don't use the remotes/ since some months now.
> But... isn't a git package with code of something like 1.4.4 is still
> in some major distributions?
Yes, AFAICT it is Ubuntu "the most up-to-date distro there is". At least
many questions on the list and in IRC suggest that.
So, how about checking (at least for a year) in builtin-fetch, if
"branches/" or "remotes/" exist, and fail, with a nice message how to move
to config-based remotes?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Johannes Schindelin @ 2007-06-19 11:09 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Junio C Hamano, Git Mailing List, Jakub Narebski
In-Reply-To: <20070619021252.GE19725@planck.djpig.de>
Hi,
On Tue, 19 Jun 2007, Frank Lichtenheld wrote:
> On Mon, Jun 18, 2007 at 06:37:35PM -0700, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > Another possibility, though, is to say:
> >
> > core.some\0where\0core.over\0\0core.the\0core.rainbow\0
>
> How do you denote empty values then?
>
> [section]
> key=
> key
>
> this are two very different statements atm (e.g. the one is false and
> the other one is true).
>
> I still think using two different delimiters is the simplest choice.
Okay, good point. But of course, you have to use a delimiter for the key
name that cannot be part of the keyname. You picked '\n'. The original was
'='. Both work.
Ciao,
Dscho
^ permalink raw reply
* Re: builtin-fetch code with messy history
From: Alex Riesen @ 2007-06-19 10:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706191037590.4059@racer.site>
On 6/19/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > * when a branch config file section refers to a branches/* remote, the
> > merge setting is used (if one is given), even though this isn't useful
> > either way.
>
> Maybe this is the right time to cut off branches/* and remotes/*?
>
Seconded. Don't use the remotes/ since some months now.
But... isn't a git package with code of something like 1.4.4 is still
in some major distributions?
^ permalink raw reply
* Re: blame follows renames, but log doesn't
From: Steven Grimm @ 2007-06-19 9:54 UTC (permalink / raw)
To: Theodore Tso; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <20070619071916.GC9177@thunk.org>
Theodore Tso wrote:
> Actually, the bigger missing gap is merges. Suppose in the
> development branch, you rename a whole bunch of files. (For example,
> foo_super.c got moved to foo/super.c, foo_inode.c got moved to
> foo/inode.c, etc.)
>
> Now suppose there are fixes made in the stable branch, in the original
> foo_super.c and foo_inode.c files. Ideally you would want to be able
> to pull those changes into the development branch, where the files
> have new names, and have the changes be applied to foo/super.c and
> foo/inode.c in the development branch.
>
I believe git handles this case already, actually. I've seen this work
just fine many times.
What git doesn't handle, but BitKeeper does, is applying directory
renames to newly created files. I rename the "lib" directory to "util",
you create a new file lib/strings.c and update lib/Makefile to compile
it. I pull from you. Under BitKeeper, I will get util/strings.c and the
change will be applied to my util/Makefile. git will create a brand-new
"lib" directory containing nothing but the new file, but since the
Makefile existed before, it will (correctly) apply your change to my
util/Makefile, which will then break my build because it will refer to a
file that doesn't exist in the Makefile's directory.
This has bitten me a few times in real life, e.g. in cases where I'm
importing a third-party source tarfile and reorganizing it a little to
fit it into my local build system. Every time they add a new source
file, I have to go manually clean up after it rather than just merging
the vendor branch into mine like I can do when they don't add anything.
It is not frequent enough to be a major hassle for me but it sure is
annoying when it happens (especially since sometimes the build *doesn't*
break and it takes a while to notice a newly created file isn't where it
should be.)
-Steve
^ permalink raw reply
* Re: Stupid quoting...
From: Johannes Schindelin @ 2007-06-19 9:50 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86sl8owfqj.fsf@lola.quinscape.zz>
Hi,
On Tue, 19 Jun 2007, David Kastrup wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Don't just throw away backwards compatibility, only because it does
> > not fit your wishes.
>
> There is no backwards compatibility involved here _at_ _all_.
I was not talking about Git here. The specification for SMTP is not going
to change just because you want it. There are still mail servers out there
which speak 7-bit, and the standard requires you to cope with them.
Ciao,
Dscho
^ 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