* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Martin Langhoff @ 2006-06-26 22:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio, martin
In-Reply-To: <Pine.LNX.4.63.0606261728340.29667@wbgn013.biozentrum.uni-wuerzburg.de>
git-format-patch is rather broken on pu right now (pre these patches).
In my test git repo, git-format-patch.sh called with 2 parameters,
like
git-format-patch <remotehead> <myhead>
when HEAD != myhead does the right thing, but git format-patch
doesn't, it seems to be messing up and not finding the merge base
correctly:
0001-Initial-revision-of-git-the-information-manager-from-hell.txt
And it errors out with ignore-if-in-upstream:
$ ./git format-patch --ignore-if-in-upstream -o .patches origin master
fatal: Not a range.
I'll retest later with these patches and post again.
martin
^ permalink raw reply
* Re: stgit: bunch of bugreports/wishes
From: Catalin Marinas @ 2006-06-26 21:04 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20060622221425.GA7851@nowhere.earth>
On 22/06/06, Yann Dirson <ydirson@altern.org> wrote:
> Here are a number of problems I encountered while playing with
> uncommit with 0.10:
"uncommit" was really intended as generating some simple patches from
a linear list of commits (maybe for undoing a "stg commit" or after a
git-am to modify some patches before pushint upstream). History
re-writing is somehow outside StGIT's goals.
> - uncommit ignores grafts. This causes "uncommit -n" to through
> "graft merges" without asking, and surely gives unexpected result
> when a graft is used to change an ancestor rather than adding one.
[...]
I could fix "uncommit" to fail at this point but, as I said above, I
wouldn't add extra features to this command.
Maybe you can explain your workflow a bit as I don't see the need for
mass uncommitting.
> - uncommit could be more flexible to help with mass-uncommitting,
> eg. with something like "--to <commit>" (to avoid counting manually),
> or "--to-merge" to cleanly stop on first merge instead of failing
> there. This may have an impact on how uncommits are numbered.
>
> - uncommit synopsis is incomplete (lacks " | -n <n> <basename>")
>
> - after mass-uncommitting, more help to look at the stack would be
> needed. Eg. a "stg series" flag to print more commit info (author,
> files), or to limit the listing to a given author (like "stg patches"
> limits for a file).
These would be good indeed. I also had a plan to generate the patch
name from the subject line (i.e. replacing the spaces with a dash) to
be more meaningful. But got really busy with my job recently and
didn't have time.
> - when a push is not committed because of a conflict, looking at the
> previous diff for the patch would help. Maybe something like "stg
> show --old" ?
"stg show <patch>//top.old" should show it (well, with a bit more
typing than --old).
> - the help string for push should say "patches", and possibly document
> more precisely the syntax, something like:
I plan to change the syntax of push a bit to allow things like
patch1..patch2 without the --to option (the latter would still be
there but taking a single patch).
> -help = 'push a patch on top of the series'
> -usage = """%prog [options] [<patch1> [<patch2>...]]
> +help = 'push patches on top of the series'
> +usage = """%prog [options] [<patch1> [<patch2>...] | -n <n> <patchroot>]
Does the <patchroot> syntax work?
> - "push --undo" is not robust. On the occasion reproduced below, I
> had to rollback the push myself by hand-modifying the stgit data,
> which took me some effort. I'll have to gather precise info, but the
> issue occurs on patch reordering, on a genuine conflict, and seems to
> be involve a change to a non-existent file, when that file would have
> been added by a non-applied patch originally below the one I attempted
> to apply.
[...]
> ydirson$ stg push --undo
> Undoing the "patch10" push...stg push: ['git-diff-index', 'HEAD', 'path/to/the/file.java'] failed (fatal: ambiguous argument
> 'path/to/the/file.java': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions)
I got this problem as well. StGIT needs fixing but I think a quick
workaround is to create an empty file (touch patch/to/the/file.java)
before the undo and git-diff-index will be happy.
Thanks for the bug reports/suggestions.
--
Catalin
^ permalink raw reply
* Re: [PATCH 0/7] Rework diff options
From: Junio C Hamano @ 2006-06-26 18:24 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <7vslltopzg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Here are a few problems I have seen:
>
> - "git show --stat HEAD" gives '---' marker as Johannes and you
> have already discussed (I do not mind this that much though);
>
> - "--cc" seems to be quite broken. "git show v1.0.0" nor "git
> diff-tree --pretty --cc v1.0.0" does not give the log
> message, and gives something quite confused instead. I think
> it is showing "-m -p" followed by "--cc".
>
> We may find more minor breakages, in addition to these, but I am
> reasonably sure we should be able to fix them in-tree.
Further impressions, while with a clean index and working tree.
First the good ones (improvements).
- "git diff-index --patch-with-raw HEAD" gives empty result;
the traditional one shows one empty line.
- "git diff-tree -p --stat" and "git diff-tree --stat -p"
works, as you planned.
- "git diff-tree --root --patch-with-raw --summary" works; the
traditional one misses --summary.
- "git show --name-only HEAD" works; the traditional one always
does --cc -p; the same for "git show -s HEAD".
Regressions, most of the minor.
- "git diff-index -p --stat HEAD" gives one empty line; the
traditional one gives empty.
- "git diff-tree --patch-with-raw HEAD" for a non-merge commit
misses the empty line between raw and patch.
- "git diff-tree --cc HEAD" for an evil merge (a merge whose
result does not match either parents, e.g. v1.0.0) shows extra
two-tree diffs (presumably HEAD^1..HEAD and HEAD^2..HEAD)
before showing what is expected. The same for "git show".
- "git show --name-only HEAD" for an evil merge similarly shows
extra two-tree diffs in --name-only format before showing
what is expected. Presumably the same bug as the above.
- "git diff-tree -c HEAD" for an evil merge shows extra newline
after the output.
- Neither "git diff-tree -m -s HEAD" for a merge, "git diff-tree -s
HEAD" for a non-merge does not squelch the output; same for
"git whatchanged".
- "git log --raw HEAD" descends into subdirectories. It
instead should show the top-level tree differences.
- "git diff-tree --pretty --patch-with-stat HEAD" for a
non-merge misses "---\n" before stat (I think you are aware
of this).
- "git show --cc HEAD" for a merge should do "---\n", followed
by a stat for diff between HEAD^1..HEAD, followed by dense
combined-diff for HEAD.
^ permalink raw reply
* Re: [PATCH] "test" in Solaris' /bin/sh does not support -e
From: Junio C Hamano @ 2006-06-26 17:03 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20060626100402.G5761a3ea@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
> Argh! Why don't they put their "standards compliant" shell to
> /bin/sh? The current one doesn't even support the $( )-style command
> substitution, so making the scripts run with that shell would be
> _really_ ugly.
Which means this in pb/gitpm topic needs further changes,
perhaps.
$ git grep -n '\$\$(' pb/gitpm:Makefile
pb/gitpm:Makefile:537: INSTLIBDIR=$$(make -s -C perl instlibdir) && \
^ permalink raw reply
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Junio C Hamano @ 2006-06-26 16:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606261728340.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It is not clean to reset the flags of all objects to 0. Instead,
> the commits are walked directly. Not that it matters in that
> particular case (the only read objects _are_ these commits).
I think this makes sense, but the clear-commit-marks function
itself looks fishy. I suspect a parent that has not been parsed
could be already marked in which case the current code would
leave it marked. Don't we need this perhaps?
diff --git a/commit.c b/commit.c
index 946615d..69fbc41 100644
--- a/commit.c
+++ b/commit.c
@@ -397,8 +397,7 @@ void clear_commit_marks(struct commit *c
commit->object.flags &= ~mark;
while (parents) {
struct commit *parent = parents->item;
- if (parent && parent->object.parsed &&
- (parent->object.flags & mark))
+ if (parent && (parent->object.flags & mark))
clear_commit_marks(parent, mark);
parents = parents->next;
}
^ permalink raw reply related
* [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Johannes Schindelin @ 2006-06-26 15:33 UTC (permalink / raw)
To: git, junkio, martin
In-Reply-To: <Pine.LNX.4.63.0606250349280.29667@wbgn013.biozentrum.uni-wuerzburg.de>
It is cleaner, and it describes better what is the idea behind the code.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This goes on top of the --ignore-if-in-upstream patch.
On Sun, 25 Jun 2006, Johannes Schindelin wrote:
> - To add the patch ids of the upstream, the revision walker must
> be called twice.
>
> So, if format-patch was called with a range "a..b" (a single
> revision "a" is handled as "a..HEAD" by format-patch), a
> revision walker is set up for "b..a", and the patch ids are
> calculated and stored. This is done by toggling the
> UNINTERESTING bits of both pending objects.
>
> After that, the flags of all objects are reset to 0, so that the
> revisions can be walked again. The flags of the two pending
> objects are then reset to their original state.
It is not clean to reset the flags of all objects to 0. Instead,
the commits are walked directly. Not that it matters in that
particular case (the only read objects _are_ these commits).
builtin-log.c | 12 ++----------
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index e78a9a4..e2cd975 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -160,15 +160,6 @@ static void reopen_stdout(struct commit
freopen(filename, "w", stdout);
}
-static void reset_all_objects_flags()
-{
- int i;
-
- for (i = 0; i < obj_allocs; i++)
- if (objs[i])
- objs[i]->flags = 0;
-}
-
static int get_patch_id(struct commit *commit, struct diff_options *options,
unsigned char *sha1)
{
@@ -220,7 +211,8 @@ static void get_patch_ids(struct rev_inf
}
/* reset for next revision walk */
- reset_all_objects_flags();
+ clear_commit_marks((struct commit *)o1, SEEN | UNINTERESTING);
+ clear_commit_marks((struct commit *)o2, SEEN | UNINTERESTING);
o1->flags = flags1;
o2->flags = flags2;
}
--
1.4.1.rc1.gc792
^ permalink raw reply related
* Re: Setting up git server?
From: Andreas Ericsson @ 2006-06-26 7:55 UTC (permalink / raw)
To: lamikr; +Cc: git
In-Reply-To: <4491EAE8.6090009@cc.jyu.fi>
lamikr wrote:
> Hi
>
> I have git-repo cloned from the linux-omap-2.6 that we have used as a
> base for our h6300 development.
> Earlier we have kept our kernel in svn (sync between git-branches and
> svn has happened about once in a month by using
> traditional diff files...)
>
> I have now pulled the server to "/repos/git/linux-omap-h6300-2.6" and
> setup the /etc/xinetd.d/git-daemon by using docs in
> http://www.kernel.org/pub/software/scm/git/docs/everyday.html
>
> How can I now create the git url for this? For example something like
> this: git://aragorn.kortex.jyu.fi/repos/git/linux-omap-h6300-2.6.git
>
Assuming '/repos' is in your root directory, do
touch /repos/git/linux-omap-h6300-2.6.git/git-daemon-export-ok
This will mark the repo as allowed to export for the git-daemon, and
then you can tell people to pull from the url you mentioned.
For those that need push access you will need to setup ssh accounts. It
is easier if they also pull over ssh+git, using a similar url but
replacing "git://" with "ssh://" (or "git+ssh://").
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] cast pid_t to long for printing
From: Uwe Zeisberger @ 2006-06-26 12:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr71ci7yt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
>
> > While fixing daemon.c, I saw that there is a call to syslog using %d for
> > pid_t, too. I fixed that in the same way without further testing and
> > manual reading. I assume that's OK.
>
> Is anybody using pid_t that is wider than int? IOW, I wonder if
> it would make more sense to use "%d" with casting to int.
See types(3HEAD) e.g. on
http://docs.sun.com/app/docs/doc/816-5173/6mbb8ae36?a=view
So it's always as long as int, but it is defined as long...
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=gravity+on+earth%3D
^ permalink raw reply
* Re: [PATCH] "test" in Solaris' /bin/sh does not support -e
From: Dennis Stosberg @ 2006-06-26 10:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <20060626094211.G3b49c5c3@leonov.stosberg.net>
Dennis Stosberg wrote:
> A lot of bashisms have been removed from the shell scripts since
> that SHELL_PATH override was added in September 2005; I will have a
> look whether it's still necessary.
Solaris is really horrible sometimes. "/bin/sh" is linked to
"/usr/bin/sh". The manual sh(1) reads:
The /usr/bin/sh utility is a command programming language
that executes commands read from a terminal or a file.
The /usr/xpg4/bin/sh utility is a standards compliant shell.
Argh! Why don't they put their "standards compliant" shell to
/bin/sh? The current one doesn't even support the $( )-style command
substitution, so making the scripts run with that shell would be
_really_ ugly.
Regards,
Dennis
^ permalink raw reply
* Re: [PATCH] "test" in Solaris' /bin/sh does not support -e
From: Dennis Stosberg @ 2006-06-26 9:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vwtb4i89d.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Dennis Stosberg <dennis@stosberg.net> writes:
>
> > Running "make clean" currently fails:
> > [ ! -e perl/Makefile ] || make -C perl/ clean
> > /bin/sh: test: argument expected
> > make: *** [clean] Error 1
>
> Ah, _BAD_. We seem to have the same in git-branch, git-checkout,
> git-clone and git-tag. You would probably need this on top of
> "master".
The SHELL_PATH in the Makefile is being set to "/bin/bash" on
Solaris, so there is currently no problem with those.
A lot of bashisms have been removed from the shell scripts since
that SHELL_PATH override was added in September 2005; I will have a
look whether it's still necessary.
Regards,
Dennis
^ permalink raw reply
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Dennis Stosberg @ 2006-06-26 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzc0i7xo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Dennis Stosberg <dennis@stosberg.net> writes:
>
> > Yesterday I could build the next branch with Sun CC 5.8 with a few
> > trivial changes. I will send four patches in reply to this mail.
>
> Thanks. Next time around please sign off your patches.
Sorry, I forgot and will do next time. Please assume the Signed-Off
is present on the first three patches.
Regards,
Dennis
^ permalink raw reply
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Junio C Hamano @ 2006-06-26 9:26 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20060626082428.G52c9608e@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
> Yesterday I could build the next branch with Sun CC 5.8 with a few
> trivial changes. I will send four patches in reply to this mail.
Thanks. Next time around please sign off your patches.
^ permalink raw reply
* Re: [PATCH] cast pid_t to long for printing
From: Junio C Hamano @ 2006-06-26 9:26 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060626082606.GC3646@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> While fixing daemon.c, I saw that there is a call to syslog using %d for
> pid_t, too. I fixed that in the same way without further testing and
> manual reading. I assume that's OK.
Is anybody using pid_t that is wider than int? IOW, I wonder if
it would make more sense to use "%d" with casting to int.
^ permalink raw reply
* Re: [PATCH] "test" in Solaris' /bin/sh does not support -e
From: Junio C Hamano @ 2006-06-26 9:19 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: Petr Baudis, git
In-Reply-To: <20060626082754.G6ec0a61e@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
> Running "make clean" currently fails:
> [ ! -e perl/Makefile ] || make -C perl/ clean
> /bin/sh: test: argument expected
> make: *** [clean] Error 1
Ah, _BAD_. We seem to have the same in git-branch, git-checkout,
git-clone and git-tag. You would probably need this on top of
"master".
-- >8 --
shell scripts: Avoid non-portable "test -e" where possible.
---
diff --git a/git-branch.sh b/git-branch.sh
index e0501ec..76971be 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -112,7 +112,7 @@ rev=$(git-rev-parse --verify "$head") ||
git-check-ref-format "heads/$branchname" ||
die "we do not like '$branchname' as a branch name."
-if [ -e "$GIT_DIR/refs/heads/$branchname" ]
+if test -f "$GIT_DIR/refs/heads/$branchname"
then
if test '' = "$force"
then
@@ -124,7 +124,7 @@ then
fi
if test "$create_log" = 'yes'
then
- mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$branchname")
+ mkdir -p "$(dirname "$GIT_DIR/logs/refs/heads/$branchname")"
touch "$GIT_DIR/logs/refs/heads/$branchname"
fi
git update-ref -m "branch: Created from $head" "refs/heads/$branchname" $rev
diff --git a/git-checkout.sh b/git-checkout.sh
index 77c2593..bfc2640 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -22,7 +22,7 @@ while [ "$#" != "0" ]; do
shift
[ -z "$newbranch" ] &&
die "git checkout: -b needs a branch name"
- [ -e "$GIT_DIR/refs/heads/$newbranch" ] &&
+ [ -f "$GIT_DIR/refs/heads/$newbranch" ] &&
die "git checkout: branch $newbranch already exists"
git-check-ref-format "heads/$newbranch" ||
die "git checkout: we do not like '$newbranch' as a branch name."
diff --git a/git-clone.sh b/git-clone.sh
index 6fa0daa..b355441 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -202,7 +202,7 @@ fi
dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
-[ -e "$dir" ] && echo "$dir already exists." && usage
+[ -d "$dir" ] && echo "$dir already exists." && usage
mkdir -p "$dir" &&
D=$(cd "$dir" && pwd) &&
trap 'err=$?; cd ..; rm -r "$D"; exit $err' 0
diff --git a/git-tag.sh b/git-tag.sh
index a0afa25..6118b00 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -63,7 +63,7 @@ done
name="$1"
[ "$name" ] || usage
-if [ -e "$GIT_DIR/refs/tags/$name" -a -z "$force" ]; then
+if [ -f "$GIT_DIR/refs/tags/$name" -a -z "$force" ]; then
die "tag '$name' already exists"
fi
shift
^ permalink raw reply related
* Re: [PATCH] include signal.h for prototype of signal()
From: Uwe Zeisberger @ 2006-06-26 8:51 UTC (permalink / raw)
To: git; +Cc: Dennis Stosberg
In-Reply-To: <20060626082323.GB3646@informatik.uni-freiburg.de>
Hello,
Oops, this patch was already posted by Dennis Stosberg in
<20060626082613.G7dd5c243@leonov.stosberg.net>. (But it lacks a
sign-off, as do his other patches.)
Uwe Zeisberger wrote:
> Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
>
> ---
>
> connect.c | 1 +
> merge-index.c | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> 46cd6d04f4531dfaf56f7f1beb4ea6c73f08015e
> diff --git a/connect.c b/connect.c
> index db7342e..6c5389b 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -3,6 +3,7 @@
> #include "pkt-line.h"
> #include "quote.h"
> #include "refs.h"
> +#include <signal.h>
> #include <sys/wait.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> diff --git a/merge-index.c b/merge-index.c
> index 190e12f..91908d8 100644
> --- a/merge-index.c
> +++ b/merge-index.c
> @@ -1,3 +1,4 @@
> +#include <signal.h>
> #include <sys/types.h>
> #include <sys/wait.h>
>
--
Uwe Zeisberger
cat /*dev/null; echo 'Hello World!';
cat > /dev/null <<*/
() { } int main() { printf("Hello World!\n");}
/* */
^ permalink raw reply
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Thomas Glanzmann @ 2006-06-26 8:51 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <20060626082939.G215d3ce6@leonov.stosberg.net>
Hello,
> -/*
> +/*l
> +
this looks like a typo in your patch.
Thomas
^ permalink raw reply
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Dennis Stosberg @ 2006-06-26 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <20060626082428.G52c9608e@leonov.stosberg.net>
Sun CC 5.8 fails with a strange error compiling diff-delta.c that
looks like an error in Sun's compiler to me:
$ cc -V
cc: Sun C 5.8 Patch 121015-02 2006/03/29
$ cc -o diff-delta.o -c -I/opt/gnu/include -D__EXTENSIONS__ \
-DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR -DNO_STRLCPY \
-DNO_SETENV -DNO_UNSETENV diff-delta.c
"diff-delta.c", line 251: identifier redeclared: create_delta
current : function(pointer to const struct delta_index \
{pointer to const void src_buf, unsigned long src_size, \
unsigned int hash_mask, array[-1] of pointer to struct index_entry {..} hash},\
pointer to const void, unsigned long, pointer to unsigned long, \
unsigned long) returning pointer to void
previous: function(pointer to const struct delta_index \
{pointer to const void src_buf, unsigned long src_size, \
unsigned int hash_mask, array[-1] of pointer to struct index_entry {..} hash},\
pointer to const void, unsigned long, pointer to unsigned long, \
unsigned long) returning pointer to void : "delta.h", line 37
cc: acomp failed for diff-delta.c
make: *** [diff-delta.o] Error 2
Yes, the two prototypes are identical. Seems like the compiler has
problems with the opaque struct. When I played around with it, I
was surprised when I found that Sun CC actually compiled this file
after I removed the const qualifier from the first parameter of the
create_delta() function. Does anybody have a better explanation
than an error in the compiler?
Regards,
Dennis
diff --git a/delta.h b/delta.h
index 7b3f86d..ec9147c 100644
--- a/delta.h
+++ b/delta.h
@@ -34,11 +34,12 @@ extern void free_delta_index(struct delt
* must be freed by the caller.
*/
extern void *
-create_delta(const struct delta_index *index,
+create_delta(struct delta_index *index,
const void *buf, unsigned long bufsize,
unsigned long *delta_size, unsigned long max_delta_size);
-/*
+/*l
+
* diff_delta: create a delta from source buffer to target buffer
*
* If max_delta_size is non-zero and the resulting delta is to be larger
diff --git a/diff-delta.c b/diff-delta.c
index 8b9172a..802be76 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -245,7 +245,7 @@ void free_delta_index(struct delta_index
#define MAX_OP_SIZE (5 + 5 + 1 + RABIN_WINDOW + 7)
void *
-create_delta(const struct delta_index *index,
+create_delta(struct delta_index *index,
const void *trg_buf, unsigned long trg_size,
unsigned long *delta_size, unsigned long max_size)
{
^ permalink raw reply related
* [PATCH] "test" in Solaris' /bin/sh does not support -e
From: Dennis Stosberg @ 2006-06-26 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <20060626082428.G52c9608e@leonov.stosberg.net>
Running "make clean" currently fails:
[ ! -e perl/Makefile ] || make -C perl/ clean
/bin/sh: test: argument expected
make: *** [clean] Error 1
---
Pasky said in #git that a simple -f test would suffice.
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 3dc54fe..d41d224 100644
--- a/Makefile
+++ b/Makefile
@@ -761,7 +761,7 @@ clean:
rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
rm -f $(htmldocs).tar.gz $(manpages).tar.gz
$(MAKE) -C Documentation/ clean
- [ ! -e perl/Makefile ] || $(MAKE) -C perl/ clean || $(MAKE) -C perl/ clean
+ [ ! -f perl/Makefile ] || $(MAKE) -C perl/ clean || $(MAKE) -C perl/ clean
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
rm -f GIT-VERSION-FILE GIT-CFLAGS
--
1.4.0
^ permalink raw reply related
* [PATCH] Fix pkt-line.h to compile with a non-GCC compiler
From: Dennis Stosberg @ 2006-06-26 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <20060626082428.G52c9608e@leonov.stosberg.net>
pkt-line.h uses GCC's __attribute__ extension but does not include
git-compat-util.h. So it will not compile with a compiler that does
not support this extension.
---
pkt-line.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/pkt-line.h b/pkt-line.h
index 9abef24..9df653f 100644
--- a/pkt-line.h
+++ b/pkt-line.h
@@ -1,6 +1,8 @@
#ifndef PKTLINE_H
#define PKTLINE_H
+#include "git-compat-util.h"
+
/*
* Silly packetized line writing interface
*/
--
1.4.0.g64e8
^ permalink raw reply related
* [PATCH] Solaris needs inclusion of signal.h for signal()
From: Dennis Stosberg @ 2006-06-26 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <20060626082428.G52c9608e@leonov.stosberg.net>
Currently the compilation fails in connect.c and merge-index.c
---
connect.c | 1 +
merge-index.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/connect.c b/connect.c
index db7342e..66e78a2 100644
--- a/connect.c
+++ b/connect.c
@@ -8,6 +8,7 @@ #include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
+#include <signal.h>
static char *server_capabilities = NULL;
diff --git a/merge-index.c b/merge-index.c
index 190e12f..0498a6f 100644
--- a/merge-index.c
+++ b/merge-index.c
@@ -1,5 +1,6 @@
#include <sys/types.h>
#include <sys/wait.h>
+#include <signal.h>
#include "cache.h"
--
1.4.0.g64e8
^ permalink raw reply related
* [PATCH] cast pid_t to long for printing
From: Uwe Zeisberger @ 2006-06-26 8:26 UTC (permalink / raw)
To: git
In-Reply-To: <20060626080912.GA3646@informatik.uni-freiburg.de>
This fixes warnings on Solaris 8.
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
---
While fixing daemon.c, I saw that there is a call to syslog using %d for
pid_t, too. I fixed that in the same way without further testing and
manual reading. I assume that's OK.
daemon.c | 9 ++++++---
upload-pack.c | 2 +-
2 files changed, 7 insertions(+), 4 deletions(-)
b339b05462efea5fee9f2b9bf70de03897a5e4ab
diff --git a/daemon.c b/daemon.c
index 1ba4d66..8641b13 100644
--- a/daemon.c
+++ b/daemon.c
@@ -368,7 +368,7 @@ static void remove_child(pid_t pid, unsi
struct child m;
deleted = (deleted + 1) % MAX_CHILDREN;
if (deleted == spawned)
- die("could not find dead child %d\n", pid);
+ die("could not find dead child %ld\n", (long)pid);
m = live_child[deleted];
live_child[deleted] = n;
if (m.pid == pid)
@@ -476,9 +476,12 @@ static void child_handler(int signo)
if (!WIFEXITED(status) || WEXITSTATUS(status) > 0)
dead = " (with error)";
if (log_syslog)
- syslog(LOG_INFO, "[%d] Disconnected%s", pid, dead);
+ syslog(LOG_INFO, "[%ld] Disconnected%s",
+ (long)pid, dead);
else
- fprintf(stderr, "[%d] Disconnected%s\n", pid, dead);
+ fprintf(stderr,
+ "[%ld] Disconnected%s\n",
+ (long)pid, dead);
}
continue;
}
diff --git a/upload-pack.c b/upload-pack.c
index 7b86f69..fdfef39 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -274,7 +274,7 @@ static void create_pack_file(void)
goto fail;
}
error("git-upload-pack: we weren't "
- "waiting for %d", pid);
+ "waiting for %ld", (long)pid);
continue;
}
if (!WIFEXITED(status) || WEXITSTATUS(status) > 0) {
--
1.1.6.g7d80e
--
Uwe Zeisberger
exit vi, lesson V:
o : q ! CTRL-V <CR> <Esc> " d d d @ d
^ permalink raw reply related
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Dennis Stosberg @ 2006-06-26 8:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vk676orjy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Do things link and work fine if we do not have the GCC specific
> options?
Yes, with this patch I can compile Git with GCC while the Perl module
gets built with Sun CC. The result even works.
If the git commands written in Perl will be converted to use Git.pm,
Sun CC will become a new dependency for Git on Solaris, unless
people build a separate Perl with GCC or manually edit the generated
Makefile in the perl subdir to build the module with GCC.
> I would question why the rest of git is not built with Sun CC as
> well if that is the case.
Well, GCC comes along with Solaris on the CDs while Sun CC is a
separate product. And usually it's easier to build free software
with GCC, because many projects use GCC extensions. Often GCC is
the only compiler installed on Solaris machines.
Until the patch series from Florian Forster removed a lot of GCC'isms
a few days ago it was not possible to build Git with Sun CC.
Yesterday I could build the next branch with Sun CC 5.8 with a few
trivial changes. I will send four patches in reply to this mail.
Junio, please consider the first two patches for inclusion into the
next branch. The third patch is on top of Pasky's changes in the pu
branch. The fourth patch is a strange workaround for a strange
problem of which I think it is an error in Sun's compiler. That one
should not make its way into Git, but maybe someone on the list has
an idea about the problem.
Regards,
Dennis
^ permalink raw reply
* [PATCH] include signal.h for prototype of signal()
From: Uwe Zeisberger @ 2006-06-26 8:23 UTC (permalink / raw)
To: git
In-Reply-To: <20060626080912.GA3646@informatik.uni-freiburg.de>
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
---
connect.c | 1 +
merge-index.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
46cd6d04f4531dfaf56f7f1beb4ea6c73f08015e
diff --git a/connect.c b/connect.c
index db7342e..6c5389b 100644
--- a/connect.c
+++ b/connect.c
@@ -3,6 +3,7 @@
#include "pkt-line.h"
#include "quote.h"
#include "refs.h"
+#include <signal.h>
#include <sys/wait.h>
#include <sys/socket.h>
#include <netinet/in.h>
diff --git a/merge-index.c b/merge-index.c
index 190e12f..91908d8 100644
--- a/merge-index.c
+++ b/merge-index.c
@@ -1,3 +1,4 @@
+#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
--
1.1.6.g7d80e
--
Uwe Zeisberger
http://www.google.com/search?q=the+speed+of+light+in+m%2Fs
^ permalink raw reply related
* Solaris 8
From: Uwe Zeisberger @ 2006-06-26 8:09 UTC (permalink / raw)
To: git
Hello,
when trying to get git running on Solaris 8 (gcc 2.95), there are
several pit-falls:
1) for me, install and tar are GNUish, ginstall and gtar don't exist.
(INSTALL = ginstall, TAR = gtar for SunOS in Makefile)
2) connect.c and merge-index.c use signal() without including signal.h
3) Solaris ships zlib 1.1.3. That version doesn't define
ZLIB_VERNUM. But no, that's not my problem, ... I have it: There is
another zlib version in /usr/local. That's 1.2.3, defining
ZLIB_VERNUM as 0x1230. The compiler uses include files from
/usr/local, but lib from /usr/lib. Aargh, I have to dig the admins
here...
4) libc don't know printf z and t modifier:
alloc.c: In function `alloc_report':
alloc.c:47: warning: unknown conversion type character `z' in format
alloc.c:47: warning: too many arguments for format
alloc.c:48: warning: unknown conversion type character `z' in format
alloc.c:48: warning: too many arguments for format
alloc.c:49: warning: unknown conversion type character `z' in format
alloc.c:49: warning: too many arguments for format
alloc.c:50: warning: unknown conversion type character `z' in format
alloc.c:50: warning: too many arguments for format
mktag.c: In function `verify_tag':
mktag.c:69: warning: unknown conversion type character `t' in format
mktag.c:69: warning: too many arguments for format
mktag.c:72: warning: unknown conversion type character `t' in format
mktag.c:72: warning: too many arguments for format
mktag.c:77: warning: unknown conversion type character `t' in format
mktag.c:77: warning: too many arguments for format
mktag.c:97: warning: unknown conversion type character `t' in format
mktag.c:97: warning: too many arguments for format
mktag.c:104: warning: unknown conversion type character `t' in format
mktag.c:104: warning: too many arguments for format
5) I don't understand why I get this warning for EMIT(c), but not for
EMIT('\\'):
quote.c:34: warning: value computed is not used
quote.c:37: warning: value computed is not used
6) typedef long pid_t
upload-pack.c: In function `create_pack_file':
upload-pack.c:277: warning: int format, pid_t arg (arg 2)
daemon.c: In function `remove_child':
daemon.c:371: warning: int format, pid_t arg (arg 2)
daemon.c: In function `child_handler':
daemon.c:481: warning: int format, pid_t arg (arg 3)
7) I think these can safely be ignored:
builtin-help.c: In function `cmd_help':
builtin-help.c:234: warning: null format string
builtin-help.c:236: warning: null format string
git.c: In function `main':
git.c:280: warning: null format string
I'll send out patches in reply to this mail for 2) and 6)
--
Uwe Zeisberger
main(){char*a="main(){char*a=%c%s%c;printf(a,34,a,34%c";printf(a,34,a,34
,10);a=",10);a=%c%s%c;printf(a,34,a,34,10);}%c";printf(a,34,a,34,10);}
^ permalink raw reply
* Re: [PATCH] correct documentation for git grep
From: Johannes Schindelin @ 2006-06-26 6:59 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1Fuecp-0004iI-RG@moooo.ath.cx>
Hi,
On Mon, 26 Jun 2006, Matthias Lederhofer wrote:
> - [-f <file>] [-e <pattern>]
> + [-f <file>] [-e] <pattern> [-e <pattern> [..]]
> [<tree>...]
> [--] [<path>...]
Minor nit: as you can see from the two latter lines, "<bla>..." is the
standard notation, whereas "<bla> [..]" is not.
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