* Re: [ANNOUNCE] GIT 0.99.7b
From: H. Peter Anvin @ 2005-09-23 19:44 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dh0uur$h4g$1@sea.gmane.org>
walt wrote:
> Junio C Hamano wrote:
>
>> GIT 0.99.7b
>
> [...]
>
>> Or, if you use git already:
>>
>> {http,rsync}://kernel.org/pub/scm/git/git.git/
>
>
> I did it that way and now I see this:
>
> $git --version
> git version 0.99.7
>
> This is a bit confusing. Did I upgrade or downgrade?
> Maybe the version string should contain the same kind
> of hexadecimal string that Linus is appending to his
> kernel version?
>
Or just call it 0.99.7.1 and .2 or 0.99.8 and .9.
-hpa
^ permalink raw reply
* Re: /bin/sh portability question
From: H. Peter Anvin @ 2005-09-23 19:48 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20050923075058.GA25473@bohr.gbar.dtu.dk>
Peter Eriksen wrote:
>
> 2) In many of the shell scripts there is the idiom:
>
> #!/bin/sh
>
> cmd=
> path=$(dirname $0)
> case "$#" in
> 0) ;;
> *) cmd="$1"
> shift
>
> When run, this gives the error:
>
> ./git.sh: syntax error at line 4: `path=$' unexpected
>
> I think it's because (on my Solaris at least), sh is really
> sh and is not symlinked to bash, and sh doesn't like that
> syntax. Are there any good solutions to this other than
> making the administrators actually change sh to a symlink,
> (which I tried)?
>
I think $(foo) is required by POSIX.
-hpa
^ permalink raw reply
* Re: /bin/sh portability question
From: Morten Welinder @ 2005-09-23 19:55 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Peter Eriksen, git
In-Reply-To: <43345C17.7060402@zytor.com>
> I think $(foo) is required by POSIX.
Indeed, but Solaris really does not have it.
Morten
^ permalink raw reply
* Re: /bin/sh portability question
From: Joel Becker @ 2005-09-23 19:57 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Peter Eriksen, git
In-Reply-To: <43345C17.7060402@zytor.com>
On Fri, Sep 23, 2005 at 12:48:39PM -0700, H. Peter Anvin wrote:
> Peter Eriksen wrote:
> > path=$(dirname $0)
> > ...
> > ./git.sh: syntax error at line 4: `path=$' unexpected
>
> I think $(foo) is required by POSIX.
I believe that Solaris and others (AIX IIRC) have /bin/sh linked
to /bin/ksh, and it behaves as the POSIX shell when run as /bin/ksh, but
behaves as a much more true-to-bourne shell when run as /bin/sh.
Joel
--
"Nearly all men can stand adversity, but if you really want to
test a man's character, give him power."
- Abraham Lincoln
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: /bin/sh portability question
From: H. Peter Anvin @ 2005-09-23 20:00 UTC (permalink / raw)
To: Joel Becker; +Cc: Peter Eriksen, git
In-Reply-To: <20050923195706.GV27375@ca-server1.us.oracle.com>
Joel Becker wrote:
> On Fri, Sep 23, 2005 at 12:48:39PM -0700, H. Peter Anvin wrote:
>
>>Peter Eriksen wrote:
>>
>>> path=$(dirname $0)
>>>...
>>> ./git.sh: syntax error at line 4: `path=$' unexpected
>>
>>I think $(foo) is required by POSIX.
>
>
> I believe that Solaris and others (AIX IIRC) have /bin/sh linked
> to /bin/ksh, and it behaves as the POSIX shell when run as /bin/ksh, but
> behaves as a much more true-to-bourne shell when run as /bin/sh.
>
But "sh" is required to be the POSIX shell (XSH page 850.)
Thus, they might have some braindamage where /usr/bin/sh is the POSIX
shell and /bin/sh is a braindead shell. Sigh.
-hpa
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.7b
From: Junio C Hamano @ 2005-09-23 20:46 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dh0uur$h4g$1@sea.gmane.org>
walt <wa1ter@myrealbox.com> writes:
> Junio C Hamano wrote:
>> GIT 0.99.7b
> [...]
>> Or, if you use git already:
>> {http,rsync}://kernel.org/pub/scm/git/git.git/
>
> I did it that way and now I see this:
If you fetched v0.99.7b tag and built it, hopefully it should
say 0.99.7b otherwise you found a big bug.
If you pulled from "master" branch, then --version would still
say 0.99.7; I agree it is confusing. On the other hand, I do
not think we would want to increment the version string with
every little changes, so...
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.7b
From: Joel Becker @ 2005-09-23 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: walt, git
In-Reply-To: <7v8xxnbjhl.fsf@assigned-by-dhcp.cox.net>
On Fri, Sep 23, 2005 at 01:46:14PM -0700, Junio C Hamano wrote:
> If you pulled from "master" branch, then --version would still
> say 0.99.7; I agree it is confusing. On the other hand, I do
> not think we would want to increment the version string with
> every little changes, so...
Every little change, no. But ANNOUNCEd releases should be
considered 'major' from this point of view. I don't think a little
extra version number incrementing is too big a deal.
Joel
--
Life's Little Instruction Book #451
"Don't be afraid to say, 'I'm sorry.'"
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.7b
From: Petr Baudis @ 2005-09-23 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: walt, git
In-Reply-To: <7v8xxnbjhl.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Sep 23, 2005 at 10:46:14PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> If you pulled from "master" branch, then --version would still
> say 0.99.7; I agree it is confusing. On the other hand, I do
> not think we would want to increment the version string with
> every little changes, so...
In ELinks, we pseudo-bump the version number from v1.2.3 to v1.2.3.CVS
(now v1.2.3.GIT) right after the release.
In Cogito, we append the commit ID current at the time of build to
cg-version output (if it was built from GIT-tracked working directory).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.7b
From: Petr Baudis @ 2005-09-23 20:55 UTC (permalink / raw)
To: Joel Becker; +Cc: Junio C Hamano, walt, git
In-Reply-To: <20050923205242.GY27375@ca-server1.us.oracle.com>
Dear diary, on Fri, Sep 23, 2005 at 10:52:42PM CEST, I got a letter
where Joel Becker <Joel.Becker@oracle.com> told me that...
> On Fri, Sep 23, 2005 at 01:46:14PM -0700, Junio C Hamano wrote:
> > If you pulled from "master" branch, then --version would still
> > say 0.99.7; I agree it is confusing. On the other hand, I do
> > not think we would want to increment the version string with
> > every little changes, so...
>
> Every little change, no. But ANNOUNCEd releases should be
> considered 'major' from this point of view. I don't think a little
> extra version number incrementing is too big a deal.
The point is that the bugfix releases aren't tagged on the master branch
but on the maint branch.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Please undo "Use git-merge instead of git-resolve in
From: Daniel Barkalow @ 2005-09-23 21:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20050923095742.GC10255@pasky.or.cz>
On Fri, 23 Sep 2005, Petr Baudis wrote:
> Dear diary, on Fri, Sep 23, 2005 at 11:34:16AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > > * cg-fetch can do with symlinked object database
> >
> > Do you mean ".git/object" in the repository you are fetching
> > into is a symlink to somewhere, or something else?
>
> Yes, exactly that. You get it by doing cg-clone -l /local/path. O(1)
> cloning, but it has its downsides and dangers which I tried to describe
> in the cg-clone documentation.
That's actually how I use git, and it works for me. (To be precise, I
have:
~/git/project.git/{objects,refs,info}
and I have
~/working/git/current-work/, with .git/{objects,refs,info} symlinks to
the above.
git fetch works fine, with the exception that remotes aren't shared
between working trees.
> > > * cg-fetch won't do useless fetches when we are already
> > > up-to-date
> >
> > Care to explain? Perhaps you are talking about rsync transport
> > (in which case I would not be surprised)?
>
> Just that if the reference pointer did not change, you don't try to pull
> any objects. Speeds things up somewhat, and now it should always work
> (well, cg-fetch has -f which makes it always try objects as well, in
> case something went wrong anyway).
I assume you mean with rsync? The current git-http-fetch won't try any
objects if the ref didn't change (or, for that matter, if we have a
different ref that's the same), and the old one would make a local check
for the objects before trying to downlaod anything.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.7b
From: Junio C Hamano @ 2005-09-23 21:45 UTC (permalink / raw)
To: Joel Becker; +Cc: walt, git
In-Reply-To: <20050923205242.GY27375@ca-server1.us.oracle.com>
Joel Becker <Joel.Becker@oracle.com> writes:
> On Fri, Sep 23, 2005 at 01:46:14PM -0700, Junio C Hamano wrote:
>> If you pulled from "master" branch, then --version would still
>> say 0.99.7; I agree it is confusing. On the other hand, I do
>> not think we would want to increment the version string with
>> every little changes, so...
>
> Every little change, no. But ANNOUNCEd releases should be
> considered 'major' from this point of view. I don't think a little
> extra version number incrementing is too big a deal.
Yes, 'maint' has the GIT_VERSION bumped in the Makefile
(0.99.7a, 0.99.7b) and that is propagated to 'git --version'.
What I was having trouble was what to do with the stuff we put
in the 'master' between 0.99.7 and 0.99.8. 'maint' was *forked*
from 0.99.7, not just tagging some midpoint in 'master' line for
obvious reasons, so the 'git --version' on the 'master' side
does not have much to do with what happens on the 'maint' side.
We could say, immediately after 0.99.7 is released, bump the
GIT_VERSION in the 'master' branch to 0.99.8-pre or something
like that.
We need to pick something that sorts after '0.99.7a', '0.99.7b',
etc. and before '0.99.8'. Somebody needs to come up with what
is appropriate for version number ordering scheme employed by
binary packaged distributions. I know 0.99.8-pre does not sort
before 0.99.8 on Debian. Probably '0.99.7zzz'?
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Martin Langhoff @ 2005-09-23 22:08 UTC (permalink / raw)
To: Peter TB Brett; +Cc: git
In-Reply-To: <14403.62.254.128.6.1127483455.squirrel@mail.twu.net>
On 9/24/05, Peter TB Brett <peter@peter-b.co.uk> wrote:
> Ah well, I'll just have to use something else -- I know Mercurial works on
> Windows. To be honest, I'd prefer to use git though; I've used it on
> other projects and it's really nice.
Petr Baudis was working on a Mercurial-GIT gateway which could be
useful, or perhaps you can use tailor.py. OTOH, if you have a unix
machine in the network, you can probably make cretive use of samba...
cheers,
martin
^ permalink raw reply
* [PATCH]: cg-clean confused by symlinks to directories
From: Pavel Roskin @ 2005-09-23 22:12 UTC (permalink / raw)
To: Petr Baudis, git
cg-clean confused by symlinks to directories
It turns out that "git-ls-files --others" shows symlinks to directories.
That shouldn't trigger internal error in cg-clean. Such symlinks should
be treated like files and removed even without the "-d" option.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-clean b/cg-clean
--- a/cg-clean
+++ b/cg-clean
@@ -111,7 +111,7 @@ clean_files()
cg-status "$xopt" -w | sed -n 's/^? //p' |
for file in $(cat); do
path="${_git_relpath}$file"
- if [ -d "$path" ]; then
+ if [ -d "$path" -a ! -L "$path" ]; then
# Sanity check, shouldn't happen
echo "FATAL: cg-status reports directories (internal error)" >&2
exit 1
--
Regards,
Pavel Roskin
^ permalink raw reply
* How to make Cogito use git-fetch-pack?
From: H. Peter Anvin @ 2005-09-23 22:20 UTC (permalink / raw)
To: Git Mailing List; +Cc: Petr Baudis
Is there any way to make Cogito use git-fetch-pack instead of
git-ssh-fetch? git+ssh:// seems to invoke the latter.
-hpa
^ permalink raw reply
* Cogito: cg-clone doesn't like packed tag objects
From: H. Peter Anvin @ 2005-09-23 22:24 UTC (permalink / raw)
To: Git Mailing List, Petr Baudis
Packed tag objects breaks Cogito when using git+ssh:// transport.
Example:
cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git
-hpa
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Petr Baudis @ 2005-09-23 22:34 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Peter TB Brett, git
In-Reply-To: <46a038f905092315081de776c3@mail.gmail.com>
Dear diary, on Sat, Sep 24, 2005 at 12:08:28AM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> told me that...
> On 9/24/05, Peter TB Brett <peter@peter-b.co.uk> wrote:
> > Ah well, I'll just have to use something else -- I know Mercurial works on
> > Windows. To be honest, I'd prefer to use git though; I've used it on
> > other projects and it's really nice.
>
> Petr Baudis was working on a Mercurial-GIT gateway which could be
> useful, or perhaps you can use tailor.py. OTOH, if you have a unix
> machine in the network, you can probably make cretive use of samba...
Clarification: that was a Monotone-GIT gateway.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [PATCH] rsh.c unterminated string
From: H. Peter Anvin @ 2005-09-23 23:30 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 269 bytes --]
The change I made to rsh.c would leave the string unterminated under
certain conditions, which unfortunately always applied! This patch
fixes this. For some reason this never bit on i386 or ppc, but bit me
on x86-64.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1065 bytes --]
Fix situation where the buffer was not properly null-terminated.
---
commit 62f7819792e7152ae0dc241ed2f7e05e10c0d345
tree 865683d54a0c4d7604711d6b74233f79291eb8ac
parent acfadcfb48e34fdc441e9cffbb385fce9693b363
author Peter Anvin <hpa@tazenda.sc.orionmulti.com> Fri, 23 Sep 2005 16:22:33 -0700
committer Peter Anvin <hpa@tazenda.sc.orionmulti.com> Fri, 23 Sep 2005 16:22:33 -0700
rsh.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/rsh.c b/rsh.c
--- a/rsh.c
+++ b/rsh.c
@@ -53,6 +53,7 @@ static int add_to_string(char **ptrp, in
char *p = *ptrp;
int size = *sizep;
int oc;
+ int err = 0;
if ( quote ) {
oc = shell_quote(p, size, str);
@@ -62,15 +63,14 @@ static int add_to_string(char **ptrp, in
}
if ( oc >= size ) {
- p[size-1] = '\0';
- *ptrp += size-1;
- *sizep = 1;
- return 1; /* Overflow, string unusable */
+ err = 1;
+ oc = size-1;
}
*ptrp += oc;
+ **ptrp = '\0';
*sizep -= oc;
- return 0;
+ return err;
}
int setup_connection(int *fd_in, int *fd_out, const char *remote_prog,
^ permalink raw reply
* cg-restore
From: Nico -telmich- Schottelius @ 2005-09-23 23:36 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 810 bytes --]
What I did:
------------------------
[1:25] hydrogenium:cinit% cg-restore contrib+tools/cinit.graph.text.c
git-checkout-cache: contrib+tools/cinit.graph.text.c already exists
Makefile: locally modified
contrib+tools/Makefile: locally modified
contrib+tools/cinit.graph.text.c: locally modified
[1:25] hydrogenium:cinit% rm contrib+tools/cinit.graph.text.c
[1:26] hydrogenium:cinit% cg-restore contrib+tools/cinit.graph.text.c
Makefile: locally modified
contrib+tools/Makefile: locally modified
[1:26] hydrogenium:cinit%
------------------------
Is this the wanted behaviour of cg-restore or should it overwrite
the specified changed file?
Nico
--
Latest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: cg-restore
From: Petr Baudis @ 2005-09-23 23:42 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Git Mailing List
In-Reply-To: <20050923233603.GE1495@schottelius.org>
Dear diary, on Sat, Sep 24, 2005 at 01:36:03AM CEST, I got a letter
where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...
> What I did:
> ------------------------
> [1:25] hydrogenium:cinit% cg-restore contrib+tools/cinit.graph.text.c
> git-checkout-cache: contrib+tools/cinit.graph.text.c already exists
> Makefile: locally modified
> contrib+tools/Makefile: locally modified
> contrib+tools/cinit.graph.text.c: locally modified
> [1:25] hydrogenium:cinit% rm contrib+tools/cinit.graph.text.c
> [1:26] hydrogenium:cinit% cg-restore contrib+tools/cinit.graph.text.c
> Makefile: locally modified
> contrib+tools/Makefile: locally modified
> [1:26] hydrogenium:cinit%
> ------------------------
>
> Is this the wanted behaviour of cg-restore or should it overwrite
> the specified changed file?
Nope, it should overwrite it only if given the -f option. The
documentation was unclear, confusing, and wrong though - I've fixed that
now, thanks.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Linus Torvalds @ 2005-09-24 0:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Peter TB Brett, Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.63.0509231537390.11109@wgmdd8.biozentrum.uni-wuerzburg.de>
On Fri, 23 Sep 2005, Johannes Schindelin wrote:
>
> It seems that the fixup of the mmap()ed regions after a fork() does not
> work properly in cygwin. Remember that cygwin just wraps the non-POSIX
> Win32API and tries to make it sort of POSIX compliant. The problem is that
> Win32API lacks a proper fork(). This is therefore emulated, and after
> that, all the mmap()ed regions have to be mapped again. That fails.
Now, I'm not a big fan of windows ("No, really? Tell us more!") but I'd
actually like it if the _core_ git stuff worked in as wide a variety of
situations as possible. Screw the shell scripts and the daemon or
secondary things like that which windows users might as well generate
their own stuff for, but I'd hope the really core stuff would work.
If I understood correctly, you said that "git-diff-tree" doesn't work due
to the fork/mmap issue. Now, I assume that means that it's the builtin
diff that has problems.
As far as I can tell, we can solve that two ways:
- make Windows always use the external diff program. That may be the
right thing to do, since then the fork() just turns into a regular
fork+exec, which is how windows works anyway.
- look at doing the diff internally.
I'm wondering if there is some stupid way to turn a diff generated by
diff_delta() into a line-based one? If you have the original file and the
xdiff, I think we should be able to just walk the original file and output
a unified diff.
Davide, maybe I'm being stupid, but I'm thinking that it might be possible
to generate a -u3 diff by basically walking the xdiff file in a linear
fashion: if the edits are in strictly ascending order, we could walk the
original file one line at a time, and keeping a buffer of the three last
lines. Then, when the file offset hits the next "edit" in the xdiff, we
start generating a line-based diff (and use the previous three lines as
the context).
Does that sound possible? Maybe somebody has even done it? Is it a stupid
idea?
I realize that it might not generate the same diff as GNU diff would do,
and maybe it's really nasty, but it sounds like it _could_ be a "cheap"
way of generating diffs, considering that we have something that already
generates xdiffs..
Linus
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Linus Torvalds @ 2005-09-24 0:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Peter TB Brett, Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.58.0509231647300.3308@g5.osdl.org>
On Fri, 23 Sep 2005, Linus Torvalds wrote:
>
> Davide, maybe I'm being stupid, but I'm thinking that it might be possible
> to generate a -u3 diff by basically walking the xdiff file in a linear
> fashion: if the edits are in strictly ascending order
Ahh, no. Looking at the xdiff format, the edits are strictly ascending in
the destination, but they may take stuff from the source in any order, so
it's not like you can generate a diff from it by just walking it.
Oh, well. I guess we're better off just using the external diff command,
even if it is slower to execve an external diff.
The GNU diff sources are hard enough to read that I don't think we want to
try to merge the unified diff generation from there.
Linus
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Johannes Schindelin @ 2005-09-24 1:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Peter TB Brett, Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.58.0509231647300.3308@g5.osdl.org>
Hi,
On Fri, 23 Sep 2005, Linus Torvalds wrote:
> On Fri, 23 Sep 2005, Johannes Schindelin wrote:
> >
> > It seems that the fixup of the mmap()ed regions after a fork() does not
> > work properly in cygwin. Remember that cygwin just wraps the non-POSIX
> > Win32API and tries to make it sort of POSIX compliant. The problem is that
> > Win32API lacks a proper fork(). This is therefore emulated, and after
> > that, all the mmap()ed regions have to be mapped again. That fails.
>
> Now, I'm not a big fan of windows ("No, really? Tell us more!") but I'd
> actually like it if the _core_ git stuff worked in as wide a variety of
> situations as possible.
It is sure worth to try to be as portable as possible. Just look at the
bugs found by running git on x86_64 (for example by HPA), which were not
apparent from x86 or PowerPC.
> Screw the shell scripts and the daemon or secondary things like that
> which windows users might as well generate their own stuff for, but I'd
> hope the really core stuff would work.
Whoa, slow! The shell scripts and the networking are important parts even
of the core git suite. Without them, work is next to impossible.
> If I understood correctly, you said that "git-diff-tree" doesn't work due
> to the fork/mmap issue. Now, I assume that means that it's the builtin
> diff that has problems.
No. It means that there is something weird going on inside cygwin1.dll.
This library works perfectly when the program is run inside gdb. Which
could well mean some timing issue. Unfortunately, I have problems
rebuilding cygwin1.dll, and therefore cannot debug in detail.
BTW I am fairly convinced that the same issues would trouble a git-pull,
once the networking is running, since the pack transfer relies on
fork()ing.
> I'm wondering if there is some stupid way to turn a diff generated by
> diff_delta() into a line-based one? If you have the original file and the
> xdiff, I think we should be able to just walk the original file and output
> a unified diff.
It sure would be nice to have a unified diff generator included, but I
doubt that a reliable (=simple) one is easy to come by.
Ciao,
Dscho
^ permalink raw reply
* Re: /bin/sh portability question
From: Junio C Hamano @ 2005-09-24 1:13 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git, Sean
In-Reply-To: <20050923121705.GA11377@sunq05.gbar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> GCC is not complaining. :-)
>
> My current make command is like this:
>
> gmake NO_STRCASESTR=YesPlease CURLDIR=/opt/sfw/ \
> SHELL_PATH=/bin/bash INSTALL=ginstall install
>
> There are two problems:
>
> * First of all there really needs to be a TAR variable,
> since Solaris tar doesn't like the C option.
>
> * Secondly I've noticed that git.sh and gitk don't get
> their /bin/sh line changed during install.
Thanks.
Would something like the attached patch, on top of what I sent
out, look good? I do not think bash vs ksh vs bourne makes a
difference in the case of gitk.
------------
[PATCH] Solaris: give a bit more built-in defaults.
Taking the make command line Peter Eriksen uses, give defaults
to SHELL_PATH, TAR, CURLDIR, NO_STRCASESTR, and INSTALL.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 43 ++++++++++++++++++++++++++-----------------
git-clone.sh | 3 ++-
templates/Makefile | 10 ++++++----
3 files changed, 34 insertions(+), 22 deletions(-)
49cbdf77449687da471ee9289796f7c480e7bd73
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -27,8 +27,6 @@
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
# Patrick Mauritz).
#
-# Define NO_GETDOMAINNAME if your library lack it (SunOS, Patrick Mauritz).
-#
# Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.
#
# Define COLLISION_CHECK below if you believe that SHA1's
@@ -63,6 +61,7 @@ GIT_PYTHON_DIR = $(prefix)/share/git-cor
CC = gcc
AR = ar
+TAR = tar
INSTALL = install
RPMBUILD = rpmbuild
@@ -133,17 +132,6 @@ ifdef WITH_SEND_EMAIL
SCRIPT_PERL += git-send-email.perl
endif
-ifndef NO_CURL
- ifdef CURLDIR
- # This is still problematic -- gcc does not want -R.
- CFLAGS += -I$(CURLDIR)/include
- CURL_LIBCURL = -L$(CURLDIR)/lib -R$(CURLDIR)/lib -lcurl
- else
- CURL_LIBCURL = -lcurl
- endif
- PROGRAMS += git-http-fetch
-endif
-
LIB_FILE=libgit.a
LIB_H = \
@@ -166,6 +154,9 @@ LIB_OBJS = \
LIBS = $(LIB_FILE)
LIBS += -lz
+#
+# Platform specific tweaks
+#
ifeq ($(shell uname -s),Darwin)
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
@@ -173,12 +164,28 @@ endif
ifeq ($(shell uname -s),SunOS)
NEEDS_SOCKET = YesPlease
NEEDS_NSL = YesPlease
+ SHELL_PATH = /bin/bash
+ NO_STRCASESTR = YesPlease
+ CURLDIR = /opt/sfw
+ INSTALL = ginstall
+ TAR = gtar
PLATFORM_DEFINES += -D__EXTENSIONS__
endif
ifneq (,$(findstring arm,$(shell uname -m)))
ARM_SHA1 = YesPlease
endif
+ifndef NO_CURL
+ ifdef CURLDIR
+ # This is still problematic -- gcc does not want -R.
+ CFLAGS += -I$(CURLDIR)/include
+ CURL_LIBCURL = -L$(CURLDIR)/lib -R$(CURLDIR)/lib -lcurl
+ else
+ CURL_LIBCURL = -lcurl
+ endif
+ PROGRAMS += git-http-fetch
+endif
+
ifndef SHELL_PATH
SHELL_PATH = /bin/sh
endif
@@ -245,6 +252,7 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
gitk
+export TAR INSTALL DESTDIR
### Build rules
all: $(PROGRAMS) $(SCRIPTS)
@@ -254,7 +262,8 @@ all:
git: git.sh Makefile
rm -f $@+ $@
- sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' <$@.sh >$@+
+ sed -e '1s|#!.*/sh|#!$(SHELL_PATH)|' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' <$@.sh >$@+
chmod +x $@+
mv $@+ $@
@@ -356,7 +365,7 @@ dist: git-core.spec git-tar-tree
./git-tar-tree HEAD $(GIT_TARNAME) > $(GIT_TARNAME).tar
@mkdir -p $(GIT_TARNAME)
@cp git-core.spec $(GIT_TARNAME)
- tar rf $(GIT_TARNAME).tar $(GIT_TARNAME)/git-core.spec
+ $(TAR) rf $(GIT_TARNAME).tar $(GIT_TARNAME)/git-core.spec
@rm -rf $(GIT_TARNAME)
gzip -f -9 $(GIT_TARNAME).tar
@@ -365,7 +374,7 @@ rpm: dist
deb: dist
rm -rf $(GIT_TARNAME)
- tar zxf $(GIT_TARNAME).tar.gz
+ $(TAR) zxf $(GIT_TARNAME).tar.gz
dpkg-source -b $(GIT_TARNAME)
cd $(GIT_TARNAME) && fakeroot debian/rules binary
@@ -380,5 +389,5 @@ clean:
rm -f git-core_$(GIT_VERSION)-*.deb git-core_$(GIT_VERSION)-*.dsc
rm -f git-tk_$(GIT_VERSION)-*.deb
$(MAKE) -C Documentation/ clean
- $(MAKE) -C templates/ clean
+ $(MAKE) -C templates clean
$(MAKE) -C t/ clean
diff --git a/git-clone.sh b/git-clone.sh
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -139,7 +139,8 @@ yes,yes)
then
HEAD=HEAD
fi
- tar Ccf "$repo" - refs $HEAD | tar Cxf "$D/.git" - || exit 1
+ (cd "$repo" && tar cf - refs $HEAD) |
+ (cd "$D/.git" && tar xf -) || exit 1
;;
*)
case "$repo" in
diff --git a/templates/Makefile b/templates/Makefile
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -1,8 +1,9 @@
# make and install sample templates
-INSTALL=install
-prefix=$(HOME)
-template_dir=$(prefix)/share/git-core/templates/
+INSTALL ?= install
+TAR ?= tar
+prefix ?= $(HOME)
+template_dir ?= $(prefix)/share/git-core/templates/
# DESTDIR=
all: boilerplates custom
@@ -35,4 +36,5 @@ clean:
install: all
$(INSTALL) -d -m755 $(DESTDIR)$(template_dir)
- tar Ccf blt - . | tar Cxf $(DESTDIR)$(template_dir) -
+ (cd blt && $(TAR) cf - .) | \
+ (cd $(DESTDIR)$(template_dir) && $(TAR) xf -)
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Petr Baudis @ 2005-09-24 1:18 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43348086.2040006@zytor.com>
Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> Packed tag objects breaks Cogito when using git+ssh:// transport.
>
> Example:
>
> cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git
I changed the code to use the git-*-fetch tools to fetch the objects
referenced by tags, so this works properly now. Thanks for the report.
It takes loooong time, unfortunately - scp -r takes its time itself on
many small files, and then we have to make a separate call to
git-ssh-fetch for each tag. Isn't that braindamaged... :/
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: How to make Cogito use git-fetch-pack?
From: Petr Baudis @ 2005-09-24 1:19 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43347F98.6020101@zytor.com>
Dear diary, on Sat, Sep 24, 2005 at 12:20:08AM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> Is there any way to make Cogito use git-fetch-pack instead of
> git-ssh-fetch? git+ssh:// seems to invoke the latter.
I just added git+packed+ssh:// to be used for this purpose.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ 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