* 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
* 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] 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] "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] 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] 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] 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] "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] "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] 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: 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
* [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: [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
* 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 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: 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 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
* [PATCH] Makefile fix for Solaris
From: Dennis Stosberg @ 2006-06-26 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5cvj1d0.fsf@assigned-by-dhcp.cox.net>
Solaris' /bin/sh does not support $( )-style command substitution
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index a326f6e..f44fbd3 100644
--- a/Makefile
+++ b/Makefile
@@ -544,7 +544,7 @@ common-cmds.h: Documentation/git-*.txt
$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/Makefile
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
rm -f $@ $@+
- INSTLIBDIR=$$(make -s -C perl instlibdir) && \
+ INSTLIBDIR=`make -s -C perl instlibdir` && \
sed -e '1s|#!.*perl\(.*\)|#!$(PERL_PATH_SQ)\1|' \
-e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
--
1.4.1.rc1.g80bff-dirty
^ permalink raw reply related
* [PATCH] Add possibility to pass CFLAGS and LDFLAGS specific to the perl subdir
From: Dennis Stosberg @ 2006-06-26 22:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5cvj1d0.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
Makefile | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index f44fbd3..306025d 100644
--- a/Makefile
+++ b/Makefile
@@ -94,6 +94,8 @@ CFLAGS = -g -O2 -Wall
LDFLAGS =
ALL_CFLAGS = $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
+PERL_CFLAGS =
+PERL_LDFLAGS =
STRIP ?= strip
prefix = $(HOME)
@@ -119,8 +121,8 @@ ### --- END CONFIGURATION SECTION ---
# Those must not be GNU-specific; they are shared with perl/ which may
# be built by a different compiler.
-BASIC_CFLAGS =
-BASIC_LDFLAGS =
+BASIC_CFLAGS = $(PERL_CFLAGS)
+BASIC_LDFLAGS = $(PERL_LDFLAGS)
SCRIPT_SH = \
git-bisect.sh git-branch.sh git-checkout.sh \
--
1.4.1.rc1.g80bff-dirty
^ permalink raw reply related
* Re: What's in git.git
From: Martin Langhoff @ 2006-06-26 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j35wp84.fsf@assigned-by-dhcp.cox.net>
On 6/25/06, Junio C Hamano <junkio@cox.net> wrote:
> - "git cvsimport" multi-branch fixes by Martin and Johannes.
Note: I have the nagging suspicion that there's a thinko in the
opening of new branches, but can't get into fixing that till later
today.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] "test" in Solaris' /bin/sh does not support -e
From: Dennis Stosberg @ 2006-06-26 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5cvj1d0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Which means this in pb/gitpm topic needs further changes,
> perhaps.
Indeed.
The second patch makes it possible to give additional CFLAGS and
LDFLAGS for compiling the perl module. Otherwise the compiler may
not be able to find headers and libraries for curl, expat and
openssl. This is needed on Solaris where these libraries will
usually be in paths like /usr/local or /opt/gnu.
With the patch Pasky started this thread with, the four patches I
sent earlier and these last two patches the pu branch compiles,
tests and installs cleanly on Solaris 9, both with Sun CC 5.8 and
GCC 4.1.1.
Regards,
Dennis
^ permalink raw reply
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Johannes Schindelin @ 2006-06-26 22:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd27j3v8.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 26 Jun 2006, Junio C Hamano wrote:
> 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))
This is probably not necessary for existing users, but it's a good change
for the future: new users might be surprised to learn that there are
unparsed objects, which still want to be handled.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Junio C Hamano @ 2006-06-26 22:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Martin Langhoff
In-Reply-To: <46a038f90606261520k7df8cb3ci7a4a609644e0be12@mail.gmail.com>
I'll be pushing out a new test for format-patch shortly in
"next".
>From ece3c67f9c8f0074cae76204a648cbfc6075bb44 Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Mon, 26 Jun 2006 15:40:09 -0700
Subject: [PATCH] t4014: add format-patch --ignore-if-in-upstream test
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
t/t4014-format-patch.sh | 69 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
new file mode 100755
index 0000000..c044044
--- /dev/null
+++ b/t/t4014-format-patch.sh
@@ -0,0 +1,69 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Junio C Hamano
+#
+
+test_description='Format-patch skipping already incorporated patches'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ for i in 1 2 3 4 5 6 7 8 9 10; do echo "$i"; done >file &&
+ git add file &&
+ git commit -m Initial &&
+ git checkout -b side &&
+
+ for i in 1 2 5 6 A B C 7 8 9 10; do echo "$i"; done >file &&
+ git update-index file &&
+ git commit -m "Side change #1" &&
+
+ for i in D E F; do echo "$i"; done >>file &&
+ git update-index file &&
+ git commit -m "Side change #2" &&
+ git tag C1 &&
+
+ for i in 5 6 1 2 3 A 4 B C 7 8 9 10 D E F; do echo "$i"; done >file &&
+ git update-index file &&
+ git commit -m "Side change #3" &&
+
+ git checkout master &&
+ git diff-tree -p C1 | git apply --index &&
+ git commit -m "Master accepts moral equivalent of #1"
+
+'
+
+test_expect_success "format-patch --ignore-if-in-upstream" '
+
+ git format-patch --stdout master..side >patch0 &&
+ cnt=`grep "^From " patch0 | wc -l` &&
+ test "$cnt" = 3
+
+'
+
+test_expect_success "format-patch --ignore-if-in-upstream" '
+
+ git format-patch --stdout \
+ --ignore-if-in-upstream master..side >patch1 &&
+ cnt=`grep "^From " patch1 | wc -l` &&
+ test "$cnt" = 2
+
+'
+
+test_expect_success "format-patch result applies" '
+
+ git checkout -b rebuild-0 master &&
+ git am -3 patch0 &&
+ cnt=`git rev-list master.. | wc -l` &&
+ test "$cnt" = 2
+'
+
+test_expect_success "format-patch --ignore-if-in-upstream result applies" '
+
+ git checkout -b rebuild-1 master &&
+ git am -3 patch1 &&
+ cnt=`git rev-list master.. | wc -l` &&
+ test "$cnt" = 2
+'
+
+test_done
--
1.4.1.rc1.g96b82
^ permalink raw reply related
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Martin Langhoff @ 2006-06-26 22:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio, martin
In-Reply-To: <Pine.LNX.4.63.0606270038200.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 27 Jun 2006, Martin Langhoff wrote:
>
> > And it errors out with ignore-if-in-upstream:
> >
> > $ ./git format-patch --ignore-if-in-upstream -o .patches origin master
> > fatal: Not a range.
>
> Could you test with "origin..master" instead of "origin master"?
Funny you mention that! Now it works ;-) and it even produces the
patches I would expect. There is something strange though. I have a
repo with ~150 pending patches to push, of which git-cherry spots ~100
as already merged upstream. So the old git-format-patch.sh would spit
50 patches, and the initial C version would do 150.
Now this version gives me 50 patches, regardless of
--ignore-if-in-upstream. Is that expected?
Also, if the two heads are identical, it still says 'Fatal: Not a
range", but that isn't so important.
cheers,
martin
^ permalink raw reply
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Johannes Schindelin @ 2006-06-26 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff
In-Reply-To: <7vr71bh6sv.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 26 Jun 2006, Junio C Hamano wrote:
> I'll be pushing out a new test for format-patch shortly in
> "next".
Thanks. I had a little test, but it was not nearly as complete as I liked
it...
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