* 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
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Johannes Schindelin @ 2006-06-26 23:00 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, junkio, martin
In-Reply-To: <46a038f90606261550p145b20a6gbe960e0abc16e8a4@mail.gmail.com>
Hi,
On Tue, 27 Jun 2006, Martin Langhoff wrote:
> 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.
The funny thing is: I did something to account for the old syntax, but
only if you specified _one_ ref, not _two_. It would be easy, but is it
needed? (I.e. are your fingers so trained on it?)
> 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?
Hell, no! Something is really wrong there.
What does "git-rev-list their..my | wc" say?
> Also, if the two heads are identical, it still says 'Fatal: Not a
> range", but that isn't so important.
This is a consequence of my being too lazy to support the old "theirs
mine" syntax (see above).
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 23:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606270057260.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > 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.
>
> The funny thing is: I did something to account for the old syntax, but
> only if you specified _one_ ref, not _two_. It would be easy, but is it
> needed? (I.e. are your fingers so trained on it?)
If possible I'd rather correct the two syntaxes once and for all now.
Maybe accept two with a warning for deprecation?
^ permalink raw reply
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Johannes Schindelin @ 2006-06-26 22:39 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, junkio, martin
In-Reply-To: <46a038f90606261520k7df8cb3ci7a4a609644e0be12@mail.gmail.com>
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"?
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Martin Langhoff (CatalystIT) @ 2006-06-26 23:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, git, junkio
In-Reply-To: <Pine.LNX.4.63.0606270057260.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> The funny thing is: I did something to account for the old syntax, but
> only if you specified _one_ ref, not _two_. It would be easy, but is it
> needed? (I.e. are your fingers so trained on it?)
My fingers are retrainable ;-)
>>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?
>
>
> Hell, no! Something is really wrong there.
>
> What does "git-rev-list their..my | wc" say?
Ok, I cooked the numbers up a bit, it was 60 total, with 10 merged
upstream. Here's what I have today:
$ git-cherry svnhead..master | grep -c '+'
52
$ git-rev-list svnhead..master | wc -l
61
$ ~/local/git/git-format-patch.sh -o .patchesold svnhead master
...
$ ls .patchesold | wc -l
52
$ ~/local/git/git format-patch -o .patchesnewall svnhead..master
...
$ ls .patchesnewall/ | wc -l
53
$ ~/local/git/git format-patch --ignore-if-in-upstream -o
.patchesnewignore svnhead..master
...
$ ls .patchesnewignore | wc -l
52
This is a public repo --
master tracks origin which is
http://git.catalyst.net.nz/git/elgg-r2.git#nzvleportfolio
svnhead is
http://git.catalyst.net.nz/git/elgg-r2.git#svnhead
cheers,
m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* [PATCH] format-patch: support really old non-range syntax, with a warning
From: Johannes Schindelin @ 2006-06-26 23:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk673h62w.fsf@assigned-by-dhcp.cox.net>
Now you can say (again)
git format-patch <theirs> <mine>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some
adhocery
On Mon, 26 Jun 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> > 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.
> >
> > The funny thing is: I did something to account for the old syntax, but
> > only if you specified _one_ ref, not _two_. It would be easy, but is it
> > needed? (I.e. are your fingers so trained on it?)
>
> If possible I'd rather correct the two syntaxes once and for all now.
> Maybe accept two with a warning for deprecation?
Here you are. (Tested once -- works great!)
builtin-log.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 44d2d13..64b2830 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -260,6 +260,11 @@ int cmd_format_patch(int argc, const cha
if (rev.pending.nr == 1) {
rev.pending.objects[0].item->flags |= UNINTERESTING;
add_head(&rev);
+ } else if (rev.pending.nr == 2
+ && !(rev.pending.objects[0].item->flags & UNINTERESTING)
+ && !(rev.pending.objects[1].item->flags & UNINTERESTING)) {
+ rev.pending.objects[0].item->flags |= UNINTERESTING;
+ fprintf(stderr, "WARNING: obsolete syntax (no range)!\n");
}
if (!use_stdout)
^ permalink raw reply related
* Re: [PATCH] Introduce Git.pm (v3)
From: Jakub Narebski @ 2006-06-26 23:20 UTC (permalink / raw)
To: Petr Baudis, git
In-Reply-To: <20060623124539.GM21864@pasky.or.cz>
Dnia piątek 23. czerwca 2006 14:45, napisałeś:
> Dear diary, on Fri, Jun 23, 2006 at 08:03:23AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Perhaps Git.pm should provide also generic, pure Perl (and slower)
>> fallback implementation (when for some reason we cannot compile XS).
>
> I fiercely want to avoid this if there is any other possible way to go
> about it - this is a path to hell of massive code duplication and
> additional work, as the number of routines will grow. If it is question
> of spending many developer-hours uselessly duplicating code in a way
> that'll be much slower than possible anyway OR building with -fPIC... ;-)
I have thought about reimplementing only the parts which are in XS. In C
one would probably write
#if can_asm
asm (...)
#else
/* C code equivalent */
#endif
In addition to allowing use of Git.pm for people who cannot compile
Git.xs, it would be helpful I guess in Git.pm development.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Johannes Schindelin @ 2006-06-26 23:21 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: Martin Langhoff, git, junkio
In-Reply-To: <44A06A8D.7080202@catalyst.net.nz>
Hi,
On Tue, 27 Jun 2006, Martin Langhoff (CatalystIT) wrote:
> > > 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?
> >
> >
> > Hell, no! Something is really wrong there.
> >
> > What does "git-rev-list their..my | wc" say?
>
> Ok, I cooked the numbers up a bit, it was 60 total, with 10 merged upstream.
> Here's what I have today:
>
> $ git-cherry svnhead..master | grep -c '+'
> 52
> $ git-rev-list svnhead..master | wc -l
> 61
>
> $ ~/local/git/git-format-patch.sh -o .patchesold svnhead master
> ...
> $ ls .patchesold | wc -l
> 52
>
> $ ~/local/git/git format-patch -o .patchesnewall svnhead..master
> ...
> $ ls .patchesnewall/ | wc -l
> 53
That is very, very strange. One more! Do you have any idea which patch it
is (53 being one more than 52 I suspect there is one slipping through)?
> $ ~/local/git/git format-patch --ignore-if-in-upstream -o .patchesnewignore
> svnhead..master
> ...
> $ ls .patchesnewignore | wc -l
> 52
Could it be that the other patches are merges? format-patch _must_ ignore
these.
> This is a public repo --
>
> master tracks origin which is
> http://git.catalyst.net.nz/git/elgg-r2.git#nzvleportfolio
>
> svnhead is
> http://git.catalyst.net.nz/git/elgg-r2.git#svnhead
Even if I do not use cogito, I will fetch them. However, that must wait
for tomorrow, as I can no longer keep awake.
Ciao,
Dscho "where do you put the middle name if your nick is only one word?"
^ 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