* Re: [PATCH 4/3] Fold get_merge_bases_clean() into get_merge_bases()
From: Linus Torvalds @ 2006-07-02 16:43 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <20060702094938.GA10944@lsrfire.ath.cx>
On Sun, 2 Jul 2006, Rene Scharfe wrote:
>
> Due to popular request ;-), change get_merge_bases() to be able to
> clean up after itself if needed by adding a cleanup parameter.
Btw, I think the symmetric thing is still wrong.
Try this:
git rev-list ^HEAD~1 HEAD...HEAD~2
which _should_ return just HEAD ("HEAD...HEAD~2" should basically expand
into "HEAD HEAD~2 ^HEAD~2")
I haven't actually tested your patch, but I think it returns HEAD and
HEAD~1.
The reason? You clear UNINTERESTING as part of clear_commit_marks(), so
HEAD~1, which was marked thus by the user, gets cleared of its mark as
part of the get_merge_bases() invocation.
I suspect the only way to fix that is to make "get_merge_bases()" not use
UNINTERESTING at all, but instead just explicitly use something like
(obj.flags & (LEFT | RIGHT)) == (LEFT | RIGHT)
instead.
Linus
^ permalink raw reply
* [POSSIBLE REGRESSION] Spurious revs after patch "revision.c: --full-history fix"
From: Marco Costalba @ 2006-07-02 12:19 UTC (permalink / raw)
To: junkio; +Cc: git
After patch "revision.c: --full-history fix" (6631c73)
I have this in git tree.
I have _manually_ ( --abbrev=nr does not apply in this case)
truncated to 7 chars the SHA to be more readable)
$ git-rev-list --topo-order --parents --remove-empty HEAD -- builtin-add.c
021b6e4 93872e0
93872e0 3c6a370
3c6a370 e8f990b
e8f990b f259339
f259339 0d78153
0d78153
b4189aa
283c8ee
$ git-rev-list --topo-order --remove-empty HEAD -- builtin-add.c
021b6e4
93872e0
3c6a370
e8f990b
f259339
0d78153
$
What it seems is that with --parents option two more spurious revs
are printed out. This revs have nothing to do with builtin-add.c, the
file is newer then both of them.
I have tested with different files and always we have spurious
revisions in case of files that were added after initial commit, and
always the erroneous revisions are older then file creation one.
This is a possible regression that breaks things (I've found it thanks
to an assert in qgit).
Marco
^ permalink raw reply
* [PATCH] instaweb: fix unportable ';' usage in sed
From: Eric Wong @ 2006-07-02 11:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0607021109540.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hint taken from Johannes. I've tested this with sed --posix on
my system with GNU sed and it works fine with and also without
it. Further portability testing/review would be good.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> ---
> Re: What's in git.git
>
> On Sun, 2 Jul 2006, Junio C Hamano wrote:
>
> > - instaweb by Eric Wong.
>
> This breaks make on _all_ platforms I have.
>
> First of all, it is _ugly_ (three invocations of sed, where one
> really is sufficient). Then, it uses the non-portable ';'
> operator, and then, the non-at-all-portable 'T'.
>
> And worst: it is unnecessary.
*Blushes* Sorry about that, I've been meaning to brush up on my
sed skills (coming from a Perl-heavy environment).
git-instaweb.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 51067d9..69aef3c 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -194,9 +194,9 @@ EOF
}
script='
-s#^\(my\|our\) $projectroot =.*#\1 $projectroot = "'`dirname $fqgitdir`'";#;
-s#\(my\|our\) $gitbin =.*#\1 $gitbin = "'$GIT_EXEC_PATH'";#;
-s#\(my\|our\) $projects_list =.*#\1 $projects_list = $projectroot;#;
+s#^\(my\|our\) $projectroot =.*#\1 $projectroot = "'`dirname $fqgitdir`'";#
+s#\(my\|our\) $gitbin =.*#\1 $gitbin = "'$GIT_EXEC_PATH'";#
+s#\(my\|our\) $projects_list =.*#\1 $projects_list = $projectroot;#
s#\(my\|our\) $git_temp =.*#\1 $git_temp = "'$fqgitdir/gitweb/tmp'";#'
gitweb_cgi () {
--
1.4.1.rc2.gbc4f
^ permalink raw reply related
* Re: A note on merging conflicts..
From: Rene Scharfe @ 2006-07-02 11:31 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Linus Torvalds, J. Bruce Fields, Junio C Hamano, git,
Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0607011937190.9789@iabervon.org>
On Sat, Jul 01, 2006 at 07:45:33PM -0400, Daniel Barkalow wrote:
> That is: (this only has the logic portion, and it's against master, so it
> isn't actually a really working patch or anything; also, it doesn't handle
> "--not a...b" correctly, whatever that should mean)
[concept patch snipped]
You mean something like the patch below? It seems to work, but in my
unscientific tests it's significant slower than the version based on
get_merge_bases() (0.17s vs 0.05s for
"git-rev-list 89719209...262a6ef7 66ae0c77...ced9456a"). Did I do
something wrong?
You had no mark_parents_left_right() in your patch. I added it because
otherwise it wouldn't remove any common commits. Was this supposed to
work some other way?
We still need an automatic test case, and a better benchmark.
diff --git a/revision.c b/revision.c
index ebee05a..8c494ee 100644
--- a/revision.c
+++ b/revision.c
@@ -339,6 +339,20 @@ static void try_to_simplify_commit(struc
commit->object.flags |= TREECHANGE;
}
+static void mark_parents_left_right(struct commit *commit)
+{
+ unsigned int flags = commit->object.flags & (RIGHT_HALF | LEFT_HALF);
+ struct commit_list *parents = commit->parents;
+
+ while (parents) {
+ struct commit *p = parents->item;
+ p->object.flags |= flags;
+ if (p->parents)
+ mark_parents_left_right(p);
+ parents = parents->next;
+ }
+}
+
static void add_parents_to_list(struct rev_info *revs, struct commit *commit, struct commit_list **list)
{
struct commit_list *parent = commit->parents;
@@ -347,6 +361,13 @@ static void add_parents_to_list(struct r
return;
commit->object.flags |= ADDED;
+ if (commit->object.flags & (RIGHT_HALF | LEFT_HALF)) {
+ if (commit->object.flags & RIGHT_HALF &&
+ commit->object.flags & LEFT_HALF)
+ commit->object.flags |= UNINTERESTING;
+ mark_parents_left_right(commit);
+ }
+
/*
* If the commit is uninteresting, don't try to
* prune parents - we want the maximal uninteresting
@@ -772,7 +793,10 @@ int setup_revisions(int argc, const char
unsigned char from_sha1[20];
const char *next = dotdot + 2;
const char *this = arg;
+ int symmetric = *next == '.';
+
*dotdot = 0;
+ next += symmetric;
if (!*next)
next = "HEAD";
if (dotdot == arg)
@@ -782,8 +806,13 @@ int setup_revisions(int argc, const char
struct object *exclude;
struct object *include;
- exclude = get_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
- include = get_reference(revs, next, sha1, flags);
+ if (symmetric) {
+ exclude = get_reference(revs, this, from_sha1, flags | LEFT_HALF);
+ include = get_reference(revs, next, sha1, flags | RIGHT_HALF);
+ } else {
+ exclude = get_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
+ include = get_reference(revs, next, sha1, flags);
+ }
if (!exclude || !include)
die("Invalid revision range %s..%s", arg, next);
diff --git a/revision.h b/revision.h
index c010a08..0090232 100644
--- a/revision.h
+++ b/revision.h
@@ -9,6 +9,8 @@ #define TMP_MARK (1u<<4) /* for isolated
#define BOUNDARY (1u<<5)
#define BOUNDARY_SHOW (1u<<6)
#define ADDED (1u<<7) /* Parents already parsed and added? */
+#define RIGHT_HALF (1u<<8)
+#define LEFT_HALF (1u<<9)
struct rev_info;
struct log_info;
^ permalink raw reply related
* Re: [POOL] Who likes running Git without make install?
From: Petr Baudis @ 2006-07-02 11:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkrcdg6d.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jul 02, 2006 at 02:05:46AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> That's fixed in ancient past in git timescale. Why are you
> bringing it up again? ;-)
Because, it is, well, not fixed? ;-) (Apparently.)
Dear diary, on Sun, Jul 02, 2006 at 02:08:07AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter
> > where Junio C Hamano <junkio@cox.net> said that...
> >> I remember myself getting utterly discusted when I saw the
> >> inclusion of the build-time blib directory in the search path in
> >> some other Perl code outside git.
> >
> > Well, yes, it is ugly, but it was really cool that we could have used
> > Git without installing it anywhere.
> >
> > But perhaps that's just me refusing to break his old ways of doing
> > things. Does anyone else care about it? (And why?)
>
> Well, for a quick test to see if I haven't broken anything, I
> use a new shell and do ". ./+denv" in my git repository where
> that file has something like this:
>
> $ cat ./+denv
> :
>
> GIT_EXEC_PATH=`pwd`
> PATH=`pwd`:/usr/bin:/bin
>
> export GIT_EXEC_PATH PATH
>
> So to a certain degree, yes I do care.
But it is currently broken:
xpasky@machine[0:0]~/git-pb$ rm -rf /home/xpasky/lib/perl5/
xpasky@machine[0:0]~/git-pb$ ./git-mv
Can't locate Git.pm in @INC (...)
(And I can't see any change that could aim to fix it.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [PATCH 4/3] Fold get_merge_bases_clean() into get_merge_bases()
From: Johannes Schindelin @ 2006-07-02 9:56 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Junio C Hamano, git
In-Reply-To: <20060702094938.GA10944@lsrfire.ath.cx>
Hi,
On Sun, 2 Jul 2006, Rene Scharfe wrote:
> Due to popular request ;-), change get_merge_bases() to be able to
> clean up after itself if needed by adding a cleanup parameter.
>
> We don't need to save the flags and restore them afterwards anymore;
> that was a leftover from before the flags were moved out of the
> range used in revision.c. clear_commit_marks() sets them to zero,
> which is enough.
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Git.xs: older perl do not know const char *
From: Johannes Schindelin @ 2006-07-02 9:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
Both of these casts _should_ be safe, since you do not want to muck around
with the version or the path anyway.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
perl/Git.xs | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/perl/Git.xs b/perl/Git.xs
index 51bfac3..c824210 100644
--- a/perl/Git.xs
+++ b/perl/Git.xs
@@ -59,7 +59,7 @@ BOOT:
# /* TODO: xs_call_gate(). See Git.pm. */
-const char *
+char *
xs_version()
CODE:
{
@@ -69,11 +69,11 @@ OUTPUT:
RETVAL
-const char *
+char *
xs_exec_path()
CODE:
{
- RETVAL = git_exec_path();
+ RETVAL = (char *)git_exec_path();
}
OUTPUT:
RETVAL
^ permalink raw reply related
* Re: [PATCH] Git.pm: Avoid ppport.h
From: Johannes Schindelin @ 2006-07-02 9:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060701234832.GD29115@pasky.or.cz>
Hi,
On Sun, 2 Jul 2006, Petr Baudis wrote:
> ow, Devel::PPPort might not be around all the way back to 5.6.0. What
> is your Perl version, BTW?
This is perl, v5.6.0 built for darwin
> This makes us not include ppport.h which seems not to give us anything real
> anyway; it is useful for checking for portability warts but since Devel::PPPort
> is a portability wart itself, we shouldn't require it for build.
Why do people introduce a "portability enhancer" like that? This is soo
dumb.
Well, your patch helped. Now the error is somewhere else:
mkdir blib
mkdir blib/lib
mkdir blib/arch
mkdir blib/arch/auto
mkdir blib/arch/auto/Git
mkdir blib/lib/auto
mkdir blib/lib/auto/Git
mkdir blib/man3
cp private-Error.pm blib/lib/Error.pm
cp Git.pm blib/lib/Git.pm
/usr/bin/perl -I/System/Library/Perl/darwin -I/System/Library/Perl
/System/Library/Perl/ExtUtils/xsubpp -typemap
/System/Library/Perl/ExtUtils/typemap Git.xs > Git.xsc && mv Git.xsc Git.c
Error: 'const char *' not in typemap in Git.xs, line 69
Error: 'const char *' not in typemap in Git.xs, line 79
make: *** [Git.c] Error 1
It seems like my typemap starts like this:
-- snip --
# $Header: /cvs/Darwin/src/live/perl/perl/lib/ExtUtils/typemap,v 1.2
2002/03/14
08:58:22 zarzycki Exp $
# basic C types
int T_IV
unsigned T_UV
unsigned int T_UV
long T_IV
unsigned long T_UV
short T_IV
unsigned short T_UV
char T_CHAR
unsigned char T_U_CHAR
char * T_PV
unsigned char * T_PV
caddr_t T_PV
wchar_t * T_PV
wchar_t T_IV
bool_t T_IV
size_t T_IV
ssize_t T_IV
time_t T_NV
-- snap --
So, no "const char *". See next mail for a minimal patch. The warning
(IIRC that was mentioned already on the list) still persists:
cc -c -I. -I.. -g -pipe -pipe -fno-common -no-cpp-precomp -flat_namespace
-DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -Os -DVERSION=\"0.01\"
-DXS_VERSION=\"0.01\" -I/System/Library/Perl/darwin/CORE -I/sw/include
-DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR -DNO_STRLCPY
-DGIT_VERSION='"1.4.1.g3b26"' Git.c
In file included from /System/Library/Perl/darwin/CORE/perl.h:500,
from Git.xs:15:
/System/Library/Perl/darwin/CORE/embed.h:156:1: warning: "die" redefined
Git.xs:11:1: warning: this is the location of the previous definition
Ciao,
Dscho
^ permalink raw reply
* [PATCH 4/3] Fold get_merge_bases_clean() into get_merge_bases()
From: Rene Scharfe @ 2006-07-02 9:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Linus Torvalds
In-Reply-To: <7vpsgpccak.fsf@assigned-by-dhcp.cox.net>
Due to popular request ;-), change get_merge_bases() to be able to
clean up after itself if needed by adding a cleanup parameter.
We don't need to save the flags and restore them afterwards anymore;
that was a leftover from before the flags were moved out of the
range used in revision.c. clear_commit_marks() sets them to zero,
which is enough.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/commit.c b/commit.c
index 70a4eff..94c1d0e 100644
--- a/commit.c
+++ b/commit.c
@@ -1012,7 +1012,8 @@ static void mark_reachable_commits(struc
}
}
-struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2)
+struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2,
+ int cleanup)
{
struct commit_list *list = NULL;
struct commit_list *result = NULL;
@@ -1080,20 +1081,10 @@ struct commit_list *get_merge_bases(stru
tmp = next;
}
- return result;
-}
-
-struct commit_list *get_merge_bases_clean(struct commit *rev1,
- struct commit *rev2)
-{
- unsigned int flags1 = rev1->object.flags;
- unsigned int flags2 = rev2->object.flags;
- struct commit_list *result = get_merge_bases(rev1, rev2);
-
- clear_commit_marks(rev1, PARENT1 | PARENT2 | UNINTERESTING);
- clear_commit_marks(rev2, PARENT1 | PARENT2 | UNINTERESTING);
- rev1->object.flags = flags1;
- rev2->object.flags = flags2;
+ if (cleanup) {
+ clear_commit_marks(rev1, PARENT1 | PARENT2 | UNINTERESTING);
+ clear_commit_marks(rev2, PARENT1 | PARENT2 | UNINTERESTING);
+ }
return result;
}
diff --git a/commit.h b/commit.h
index 3a26e29..779ed82 100644
--- a/commit.h
+++ b/commit.h
@@ -105,7 +105,6 @@ struct commit_graft *read_graft_line(cha
int register_commit_graft(struct commit_graft *, int);
int read_graft_file(const char *graft_file);
-extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2);
-extern struct commit_list *get_merge_bases_clean(struct commit *rev1, struct commit *rev2);
+extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2, int cleanup);
#endif /* COMMIT_H */
diff --git a/merge-base.c b/merge-base.c
index b41f76c..59f723f 100644
--- a/merge-base.c
+++ b/merge-base.c
@@ -6,7 +6,7 @@ static int show_all = 0;
static int merge_base(struct commit *rev1, struct commit *rev2)
{
- struct commit_list *result = get_merge_bases(rev1, rev2);
+ struct commit_list *result = get_merge_bases(rev1, rev2, 0);
if (!result)
return 1;
diff --git a/revision.c b/revision.c
index 1da6ce3..7865fa4 100644
--- a/revision.c
+++ b/revision.c
@@ -814,7 +814,7 @@ int setup_revisions(int argc, const char
}
if (symmetric) {
- exclude = get_merge_bases_clean(a, b);
+ exclude = get_merge_bases(a, b, 1);
add_pending_commit_list(revs, exclude,
flags_exclude);
a->object.flags |= flags;
^ permalink raw reply related
* [PATCH] Makefile: replace ugly and unportable sed invocation
From: Johannes Schindelin @ 2006-07-02 9:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7145u17.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Re: What's in git.git
On Sun, 2 Jul 2006, Junio C Hamano wrote:
> - instaweb by Eric Wong.
This breaks make on _all_ platforms I have.
First of all, it is _ugly_ (three invocations of sed, where one
really is sufficient). Then, it uses the non-portable ';'
operator, and then, the non-at-all-portable 'T'.
And worst: it is unnecessary.
Makefile | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 7481ad9..90ad991 100644
--- a/Makefile
+++ b/Makefile
@@ -562,11 +562,11 @@ git-instaweb: git-instaweb.sh gitweb/git
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
-e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
- $@.sh | sed \
- -e 's|@@GITWEB_CGI@@|#!$(PERL_PATH_SQ)|; T; r gitweb/gitweb.cgi' \
- | sed \
- -e 's|@@GITWEB_CSS@@||; T; r gitweb/gitweb.css' \
- > $@+
+ -e '/@@GITWEB_CGI@@/rgitweb/gitweb.cgi' \
+ -e '/@@GITWEB_CGI@@/d' \
+ -e '/@@GITWEB_CSS@@/rgitweb/gitweb.css' \
+ -e '/@@GITWEB_CSS@@/d' \
+ $@.sh > $@+
chmod +x $@+
mv $@+ $@
--
1.4.1.g1089
^ permalink raw reply related
* Re: [PATCH 1/3] Add read_cache_from() and discard_cache()
From: Johannes Schindelin @ 2006-07-02 8:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64ihdupr.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 1 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > True, I missed that one. But it is just a call to
> > cache_tree_free(active_cache_tree); in discard_cache(), right?
>
> On the codepath to write out the new index file, calling
> cache_free_tree(&active_cache_tree) before write_cache() is all that
> should be needed. When "active_cache_tree == NULL", write_cache() would
> write out an index file without the cached tree information.
>
> Currently not many things take advantage of cached tree information to
> optimize its operation. But I'd like to change that. For example, tree
> merges by read-tree should be able to take advantage of the fact that a
> cached tree read from the index and three trees being read all match for
> a subdirectory and do the merge of the directory without descending into
> it.
Together with my argument, that a library function should make life easier
for you, not harder, you are making a fine point that the _clean() version
of get_merge_bases() should clean the active_cache_tree, too.
Besides, is it not better to clean up now-bogus memory anyway?
> >> - index_timestamp is left as the old value in this patch when
> >> you switch cache using read_cache_from() directly. I have a
> >> suspicion you may be bitten by "Racy Git" problem, especially
> >> because the operations are supposed to happen quickly thanks
> >> to the effort of you two ;-) increasing the risks that the
> >> file timestamp of the working tree file and the cached entry
> >> match.
> >
> > Yes. Again, just one line to discard_cache(), right?
> >
> > index_file_timestamp = 0;
>
> This one I am not sure. Read the comment in ce_match_stat() and
> see the problematic sequence of events that this variable tries
> to help resolve applies to your use.
Okay. After reading the comment, I am quite certain we can just set the
index_file_timestamp to 0.
Either we start with an empty cache; In that case it is obviously correct
to set the timestamp to 0.
Or, after we discard the cache, we have to read a new cache before working
on it. Now, reading the cache means calling read_cache() (or
read_cache_from()), and -- alas -- line number 12 in the body of that
function sets the timestamp to 0 _anyway_, to be reset to the correct
value later.
So, I still think that these two lines should be in the cleanup part of
get_merge_bases().
BTW personally, I prefer the one-function approach, i.e. a flag which says
if it is okay not to clean up.
Ciao,
Dscho
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-07-02 7:45 UTC (permalink / raw)
To: git
The 'master' branch has been pushed out as GIT 1.4.1 tonight to
celebrate the birthday of lady gitster.
In "next", there are the following series:
- rationalize diff output options by Timo Hirvonen.
This makes "diff --patch --stat" operate sensibly. I have
added about 100 tests to make sure that this does not regress
diff/log commands, and made small fixups to Timo's version
here and there.
There are still slight differences in output between the
current "master" version and Timo's version, but I believe
they are all improvements. Curious people may want to take a
look at the following two commits that updates the tests to
match Timo's output:
commit 026625e78eaf8ea2ae960525c367b5e8f1629fd4
commit 9e76bab14e50c46c624ae35f13c527a7a1b1185d
I think this is ready to be merged into "master", but further
testing is appreciated.
- A few Makefile clean-ups by Jakub Narebski.
This is part of Jakub's "optionally manage config.mk with
autoconf generated configure script" series. I have not been
queueing the rest of the series but judging from the list
traffic and the size and quality of the later pieces, the
patch series might have stabilized enough to be resubmitted
for consideration. Honestly, I am still somewhat reluctant,
but my impression was it was still strictly "opt-in" so it
might be OK.
- git_merge_bases() by Johannes.
Calling commit ancestry walkers more than once correctly is
hard, and that is why I have accepted the libifying part with
the change to use the lib by one caller that calls the
function only once, without merging anything that calls the
function more than once.
I think this library part, with the clean-up by Rene Scharfe
in "pu", is in good shape to be tested further. The '...'
operator work would be a good demonstration to prove the
libification is sound, before proceeding to bigger and more
interesting users, like merge-recursive in C by Alex Riesen.
Alex/Johannes team's effort seems to be progressing nicely
and I am looking forward to seeing a version that is stable
enough for testing.
- gitweb updates by Dennis Stosberg and Luben Tuikov.
I am personally running this on my private machine to see the
progress made by Jakub so far with these updates, and am
generally happy. I'd like to see the code further refactored
before picking up any more new features, though. I see Jakub
is talking with xmms2 team and am hoping to see we can see
more cleanups they made in our tree soon (thanks Jakub).
- instaweb by Eric Wong.
I made a mismerge when accepting this series and "next" ended
up with two copies of three "gitweb" related patches. Sorry
for cluttering the history.
- "A better scheduled PPC SHA-1 implementation" by linux@horizon.com
- git-merge-tree WIP by Linus.
I should take a look at this and follow it through but
haven't spent as much time as I should have nor I would have
liked yet.
In "pu", there are more interesting pieces:
- updates to git-merge-bases with '...' operator by Rene Scharfe.
This should come in "next" but I think Johannes has a point
that library interface should be the easier-to-use version.
Maybe we should have get_merge_bases_unclean() as an oddball
function that does not clean up for performance, and make
git-merge-base call that, and keep the name of the function
for generic callers that does clean up short and sweet
get_merge_bases().
- updates to diff options rationalization by Timo Hirvonen.
This makes --name-only, --name-status, --check and -s
mutually exclusive, and makes 'git diff-files -s' behave like
other diff commands (i.e. -s means "silent" -- so no output
is seen). These are both optional.
- "Perly Git" series by Pasky and Pavel Roskin.
I've heard success stories from some but negatives from
others. Feedback from people other than who are on Linux
i386/x86-64 with Perl 5.8 are appreciated.
In order to get a bit wider exposure without disrupting
people, we might want to revert the fmt-merge-msg conversion
with a workaround option in Makefile to allow skipping the
build of perl/ subdirectory, and merge the result to "next".
- GIT_TRACE by Matthias Lederhofer.
- "git grep boolean expression" by me.
I am not personally interested in these two very much, but I
do not think they break anything. I may push them to "next"
or keep them lingering on in "pu". I do not care too much
either way myself -- people who are interested need to push
my back.
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.1
From: Junio C Hamano @ 2006-07-02 6:33 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest feature release GIT 1.4.1 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.1.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.1.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.1-1.$arch.rpm (RPM)
As announced earlier, 1.4.1 is not just 1.4.0 plus bugfixes, but
also has enhancements from the "master" branch.
----------------------------------------------------------------
Changes since v1.4.0 are as follows:
Andre Noll:
object-refs: avoid division by zero
Andreas Ericsson:
git wrapper: fix command name in an error message.
David Woodhouse:
Log peer address when git-daemon called from inetd
Dennis Stosberg:
Make t4101-apply-nonl bring along its patches
Make t8001-annotate and t8002-blame more portable
Fix t8001-annotate and t8002-blame for ActiveState Perl
Solaris needs inclusion of signal.h for signal()
Fix pkt-line.h to compile with a non-GCC compiler
Fix expr usage for FreeBSD
Eric W. Biederman:
Don't parse any headers in the real body of an email message.
Fix git-format-patch -s
Check and document the options to prevent mistakes.
Eric Wong:
git-svn: t0000: add -f flag to checkout
git-svn: fix handling of filenames with embedded '@'
git-svn: eol_cp corner-case fixes
git-svn: restore original LC_ALL setting (or unset) for commit
git-svn: don't allow commit if svn tree is not current
git-svn: support -C<num> passing to git-diff-tree
git-svn: --branch-all-refs / -B support
git-svn: optimize --branch and --branch-all-ref
git-svn: support manually placed initial trees from fetch
git-svn: Move all git-svn-related paths into $GIT_DIR/svn
git-svn: minor cleanups, extra error-checking
git-svn: add --repack and --repack-flags= options
git-svn: add --shared and --template= options to pass to init-db
git-svn: add some functionality to better support branches in svn
git-svn: add UTF-8 message test
git-svn: add 'log' command, a facsimile of basic `svn log'
git-svn: add support for Perl SVN::* libraries
git-svn: make the $GIT_DIR/svn/*/revs directory obsolete
git-svn: avoid creating some small files
git-svn: fix several small bugs, enable branch optimization
git-svn: Eliminate temp file usage in libsvn_get_file()
git-svn: bugfix and optimize the 'log' command
git-svn: tests no longer fail if LC_ALL is not a UTF-8 locale
git-svn: svn (command-line) 1.0.x compatibility
git-svn: rebuild convenience and bugfixes
git-svn: fix --rmdir when using SVN:: libraries
rebase: Allow merge strategies to be used when rebasing
rebase: error out for NO_PYTHON if they use recursive merge
git-svn: fix commit --edit flag when using SVN:: libraries
rebase: allow --merge option to handle patches merged upstream
rebase: cleanup rebasing with --merge
rebase: allow --skip to work with --merge
git-svn: SVN 1.1.x library compatibility
git-svn: several graft-branches improvements
git-svn: add the commit-diff command
git-svn: add --follow-parent and --no-metadata options to fetch
git-svn: be verbose by default on fetch/commit, add -q/--quiet option
rebase: get rid of outdated MRESOLVEMSG
rebase: check for errors from git-commit
git-svn: allow a local target directory to be specified for init
Florian Forster:
gitweb: Adding a `blame' interface.
gitweb: Make the `blame' interface in gitweb optional.
Remove ranges from switch statements.
Initialize FAMs using `FLEX_ARRAY'.
Don't instantiate structures with FAMs.
Cast pointers to `void *' when used in a format.
Don't use empty structure initializers.
Change types used in bitfields to be `int's.
Remove all void-pointer arithmetic.
Fredrik Kuivinen:
blame: Add --time to produce raw timestamps
Jakub Narebski:
Update gitweb README: gitweb is now included with git
Move gitweb style to gitweb.css
gitweb: safely output binary files for 'blob_plain' action
gitweb: text files for 'blob_plain' action without charset by default
Fix gitweb stylesheet
Make CSS file gitweb/gitweb.css more readable
gitweb: add type="text/css" to stylesheet link
Fix: Support for the standard mime.types map in gitweb
gitweb: A couple of page title tweaking
gitweb: style done with stylesheet
gitweb: whitespace cleanup
Add git version to gitweb output
Move $gitbin earlier in gitweb.cgi
gitweb: Make use of $PATH_INFO for project parameter
gitweb: whitespace cleanup around '='
Jeff King:
git-commit: allow -e option anywhere on command line
quote.c: silence compiler warnings from EMIT macro
Johannes Schindelin:
diff options: add --color
Initialize lock_file struct to all zero.
Fix setting config variables with an alternative GIT_CONFIG
Read configuration also from $HOME/.gitconfig
repo-config: Fix late-night bug
git_config: access() returns 0 on success, not > 0
patch-id: take "commit" prefix as well as "diff-tree" prefix
Teach diff about -b and -w flags
cvsimport: always set $ENV{GIT_INDEX_FILE} to $index{$branch}
apply: replace NO_ACCURATE_DIFF with --inaccurate-eof runtime flag.
add diff_flush_patch_id() to calculate the patch id
format-patch: introduce "--ignore-if-in-upstream"
t4014: fix for whitespace from "wc -l"
format-patch: use clear_commit_marks() instead of some ad-hockery
Save errno in handle_alias()
Junio C Hamano:
read-tree: --prefix=<path>/ option.
write-tree: --prefix=<path>
read-tree: reorganize bind_merge code.
fetch-pack: give up after getting too many "ack continue"
Fix earlier mismerges.
shared repository: optionally allow reading to "others".
gitk: rereadrefs needs listrefs
fix git alias
t5100: mailinfo and mailsplit tests.
mailinfo: ignore blanks after in-body headers.
fix rfc2047 formatter.
xdiff: minor changes to match libxdiff-0.21
Restore SIGCHLD to SIG_DFL where we care about waitpid().
checkout -f: do not leave untracked working tree files.
upload-pack: avoid sending an incomplete pack upon failure
upload-pack: prepare for sideband message support.
Retire git-clone-pack
upload-pack/fetch-pack: support side-band communication
Add renaming-rebase test.
daemon: send stderr to /dev/null instead of closing.
rebase --merge: fix for rebasing more than 7 commits.
Makefile: do not force unneeded recompilation upon GIT_VERSION changes
Makefile: do not recompile main programs when libraries have changed.
usage: minimum type fix.
git-pull: abort when fmt-merge-msg fails.
git-merge --squash
diff --color: use reset sequence when we mean reset.
repo-config: fix printing of bool
diff --color: use $GIT_DIR/config
git-repack: Be careful when updating the same pack as an existing one.
t4014: add format-patch --ignore-if-in-upstream test
combine-diff.c: type sanity
connect.c: remove unused parameters from tcp_connect and proxy_connect
connect.c: check the commit buffer boundary while parsing.
t/README: start testing porcelainish
checkout -m: fix read-tree invocation
t4014: fix test commit labels.
diff.c: fix get_patch_id()
Racy GIT (part #3)
upload-pack.c: <sys/poll.h> includes <ctype.h> on OpenBSD 3.8
Linus Torvalds:
gitweb.cgi history not shown
Shrink "struct object" a bit
Move "void *util" from "struct object" into "struct commit"
Some more memory leak avoidance
Remove "refs" field from "struct object"
Add specialized object allocator
Add "named object array" concept
Fix grow_refs_hash()
Tweak diff colors
Do not try futile object pairs when repacking.
Abstract out accesses to object hash array
revision.c: --full-history fix.
git object hash cleanups
Lukas Sandström:
Make git-write-tree a builtin
Make git-mailsplit a builtin
Make git-mailinfo a builtin
Make git-stripspace a builtin
Make git-update-index a builtin
Make git-update-ref a builtin
Martin Langhoff:
cvsimport: ignore CVSPS_NO_BRANCH and impossible branches
cvsimport: complete the cvsps run before starting the import
cvsimport: keep one index per branch during import
git-repack -- respect -q and be quiet
cvsimport: setup indexes correctly for ancestors and incremental imports
cvsimport - cleanup of the multi-indexes handling
Matthias Kestenholz:
add GIT-CFLAGS to .gitignore
Matthias Lederhofer:
correct documentation for git grep
Nicolas Pitre:
consider previous pack undeltified object state only when reusing delta data
don't load objects needlessly when repacking
Paul Eggert:
date.c: improve guess between timezone offset and year.
Paul Mackerras:
Fix PPC SHA1 routine for large input buffers
Peter Eriksen:
Implement safe_strncpy() as strlcpy() and use it more.
Rename safe_strncpy() to strlcpy().
Petr Baudis:
Support for extracting configuration from different files
Support for the standard mime.types map in gitweb
Customizable error handlers
Fix errno usage in connect.c
Rene Scharfe:
git-tar-tree: Simplify write_trailer()
git-tar-tree: documentation update
git-tar-tree: no more void pointer arithmetic
Make release tarballs friendlier to older tar versions
Robin Rosenberg:
Minor documentation fixup.
Sean Estabrooks:
Add a "--notags" option for git-p4import.
Sven Verdoolaege:
git-cvsexportcommit.perl: fix typo
Timo Hirvonen:
gitweb: Use $hash_base as $search_hash if possible
git-merge: Don't use -p when outputting summary
Clean up diff.c
Make some strings const
Uwe Zeisberger:
Fix possible out-of-bounds array access
Yakov Lerner:
auto-detect changed prefix and/or changed build flags
Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
Yann Dirson:
git-commit: filter out log message lines only when editor was run.
^ permalink raw reply
* Re: [PATCH] gitweb: add --full-history to history generation optimization
From: Junio C Hamano @ 2006-07-02 5:22 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20060702044206.75887.qmail@web31806.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Now that Linus fixed full history generation, we can
> add this to the optimized history generation.
Thanks. I believe I have the same change in "next" already, but
I had to munge your patches by hand so please holler if there is
any mistake on my part.
^ permalink raw reply
* [PATCH] gitweb: add --full-history to history generation optimization
From: Luben Tuikov @ 2006-07-02 4:42 UTC (permalink / raw)
To: git
Now that Linus fixed full history generation, we can
add this to the optimized history generation.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.cgi | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index d808900..934af4a 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -2296,7 +2296,7 @@ sub git_history {
"</div>\n";
print "<div class=\"page_path\"><b>/" . esc_html($file_name) . "</b><br/></div>\n";
- open my $fd, "-|", "$gitbin/git-rev-list $hash -- \'$file_name\'";
+ open my $fd, "-|", "$gitbin/git-rev-list --full-history $hash -- \'$file_name\'";
print "<table cellspacing=\"0\">\n";
my $alternate = 0;
while (my $line = <$fd>) {
--
1.4.1.rc2.gffcf
^ permalink raw reply related
* Re: [PATCH] Minor documentation fixup.
From: Junio C Hamano @ 2006-07-02 0:10 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200607020207.40552.robin.rosenberg.lists@dewire.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] Fix errno usage in connect.c
From: Junio C Hamano @ 2006-07-02 0:09 UTC (permalink / raw)
To: Petr Baudis, Morten Welinder; +Cc: git
In-Reply-To: <20060701215626.GB29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Wed, Jun 28, 2006 at 06:56:12PM CEST, I got a letter
> where Morten Welinder <mwelinder@gmail.com> said that...
>> It looks like connect.c waits too long before it uses errno in both copies
>> of git_tcp_connect_sock. Both close and freeaddrinfo can poke any
>> non-zero value in there.
>
> Nice catch.
>
> ->8-
>
> errno was used after it could've been modified by a subsequent library call.
> Spotted by Morten Welinder.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
Thanks.
^ permalink raw reply
* Re: A note on merging conflicts..
From: Linus Torvalds @ 2006-07-02 0:08 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: J. Bruce Fields, Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607011905030.9789@iabervon.org>
On Sat, 1 Jul 2006, Daniel Barkalow wrote:
>
> But that wouldn't actually affect b...c, because we don't actually care
> that 'e' is the correct merge-base and 'g' is not, because "b c ^e ^g" is
> the same as "b c ^e".
You're right - in ths case we don't care about a minimal base commit set
at all, it's fine to have too many.
I think your patch to do the LEFT/RIGHT thing in git-rev-list internally,
instead of generating it as part of the command line, looks fine in
theory.
Except I think you need to set "revs->limited" for that case too (normally
it gets set by "handle_commit()", and only if there is an UNINTERESTING
commit: we'd need to add code to set it for LEFT/RIGHT commits too.
Linus
^ permalink raw reply
* Re: [POOL] Who likes running Git without make install?
From: Junio C Hamano @ 2006-07-02 0:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060701235906.GE29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> I remember myself getting utterly discusted when I saw the
>> inclusion of the build-time blib directory in the search path in
>> some other Perl code outside git.
>
> Well, yes, it is ugly, but it was really cool that we could have used
> Git without installing it anywhere.
>
> But perhaps that's just me refusing to break his old ways of doing
> things. Does anyone else care about it? (And why?)
Well, for a quick test to see if I haven't broken anything, I
use a new shell and do ". ./+denv" in my git repository where
that file has something like this:
$ cat ./+denv
:
GIT_EXEC_PATH=`pwd`
PATH=`pwd`:/usr/bin:/bin
export GIT_EXEC_PATH PATH
So to a certain degree, yes I do care.
^ permalink raw reply
* [PATCH] Minor documentation fixup.
From: Robin Rosenberg @ 2006-07-02 0:07 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Documentation/git-commit.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 0fe66f2..517a86b 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -15,9 +15,9 @@ SYNOPSIS
DESCRIPTION
-----------
Updates the index file for given paths, or all modified files if
-'-a' is specified, and makes a commit object. The command
-VISUAL and EDITOR environment variables to edit the commit log
-message.
+'-a' is specified, and makes a commit object. The command specified
+by either the VISUAL or EDITOR environment variables are used to edit
+the commit log message.
Several environment variable are used during commits. They are
documented in gitlink:git-commit-tree[1].
^ permalink raw reply related
* Re: [POOL] Who likes running Git without make install?
From: Junio C Hamano @ 2006-07-02 0:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060701235906.GE29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> I remember myself getting utterly discusted when I saw the
>> inclusion of the build-time blib directory in the search path in
>> some other Perl code outside git.
>
> Well, yes, it is ugly, but it was really cool that we could have used
> Git without installing it anywhere.
>
> But perhaps that's just me refusing to break his old ways of doing
> things. Does anyone else care about it? (And why?)
>
>> Worse yet, I suspect the order you do the two directories is
>> wrong to prefer the freshly built one over the one you installed
>> the last time, but I was trying not to stare at too much for
>> health reasons so ... ;-).
>
> Oh man, of course you are right. :-)
That's fixed in ancient past in git timescale. Why are you
bringing it up again? ;-)
^ permalink raw reply
* Git at Ottawa Linux Symposium
From: Petr Baudis @ 2006-07-02 0:02 UTC (permalink / raw)
To: git; +Cc: junkio, jdl
Hi,
as a reminder and quick invitation, there will be quite some
Git-related stuff going on at the Ottawa Linux Symposium 2006 between
Jul 19 and Jul 22. The schedule is available at:
http://www.linuxsymposium.org/2006/schedule.php
Of particular interest for the local population should be the Git BOF
session on Wednesday afternoon that Junio and me will hold. If you want
to discuss Git as its users or as its developers, we are looking forward
to meet you.
Furthermore, on Thursday early afternoon there will be three Git
events in a row! First I will try to gently introduce (Co)git(o)
to the newbie audience, then in another room Junio will give a talk
about how Git feels like and how maintaining Git feels like, and then
the crowd will scurry back to the tutorial room to watch jdl showing
the raw power of lowlevel git unleashed.
Happy summer,
Petr "Pasky" Baudis
^ permalink raw reply
* [POOL] Who likes running Git without make install?
From: Petr Baudis @ 2006-07-01 23:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk674mmyo.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Jun 26, 2006 at 08:48:31AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> I remember myself getting utterly discusted when I saw the
> inclusion of the build-time blib directory in the search path in
> some other Perl code outside git.
Well, yes, it is ugly, but it was really cool that we could have used
Git without installing it anywhere.
But perhaps that's just me refusing to break his old ways of doing
things. Does anyone else care about it? (And why?)
> Worse yet, I suspect the order you do the two directories is
> wrong to prefer the freshly built one over the one you installed
> the last time, but I was trying not to stare at too much for
> health reasons so ... ;-).
Oh man, of course you are right. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* [PATCH] Git.pm: Avoid ppport.h
From: Petr Baudis @ 2006-07-01 23:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606280938420.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Wed, Jun 28, 2006 at 09:39:46AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> on my iBook, make in pu outputs:
>
> GIT_VERSION = 1.4.1.rc1.gf5d3
> * new build flags or prefix
> (cd perl && /usr/bin/perl Makefile.PL \
> PREFIX='/Users/gene099' \
> DEFINE=' -I/sw/include -DSHA1_HEADER='\''<openssl/sha.h>'\''
> -DNO_STRCASESTR -DNO_STRLCPY -DGIT_VERSION='\''"1.4.1.rc1.gf5d3"'\''' \
> LIBS=' -L/sw/lib -lz -liconv -lcrypto -lssl')
> Can't locate Devel/PPPort.pm in @INC (@INC contains:
> /System/Library/Perl/darwin /System/Library/Perl /Library/Perl/darwin
> /Library/Perl /Library/Perl /Network/Library/Perl/darwin
> /Network/Library/Perl /Network/Library/Perl .) at Makefile.PL line 29.
> BEGIN failed--compilation aborted at Makefile.PL line 29.
> make: *** [perl/Makefile] Error 2
ow, Devel::PPPort might not be around all the way back to 5.6.0. What
is your Perl version, BTW?
->8-
This makes us not include ppport.h which seems not to give us anything real
anyway; it is useful for checking for portability warts but since Devel::PPPort
is a portability wart itself, we shouldn't require it for build. You can check
for portability problems by calling make check in perl/.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
perl/Git.xs | 2 --
perl/Makefile.PL | 10 +++++-----
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/perl/Git.xs b/perl/Git.xs
index cb23261..51bfac3 100644
--- a/perl/Git.xs
+++ b/perl/Git.xs
@@ -15,8 +15,6 @@ #include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
-#include "ppport.h"
-
#undef die
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 25ae54a..97ee9af 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -5,6 +5,11 @@ sub MY::postamble {
instlibdir:
@echo '$(INSTALLSITEARCH)'
+check:
+ perl -MDevel::PPPort -le 'Devel::PPPort::WriteFile(".ppport.h")' && \
+ perl .ppport.h --compat-version=5.6.0 Git.xs && \
+ rm .ppport.h
+
MAKE_FRAG
}
@@ -24,8 +29,3 @@ WriteMakefile(
MYEXTLIB => '../libgit.a',
INC => '-I. -I..',
);
-
-
-use Devel::PPPort;
-
--s 'ppport.h' or Devel::PPPort::WriteFile();
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply related
* Re: A note on merging conflicts..
From: Daniel Barkalow @ 2006-07-01 23:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: J. Bruce Fields, Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607011905030.9789@iabervon.org>
On Sat, 1 Jul 2006, Daniel Barkalow wrote:
> Actually, I think that it would work to have object flags "LEFT" and
> "RIGHT", mark b with left, mark c with right, and mark anything with both
> LEFT and RIGHT as UNINTERESTING as we go through the revisions. The
> time-ordering problem with symmetric difference isn't absent with regular
> difference, and, assuming that b..c works in the tricky cases, the same
> logic should handle symmetric difference.
That is: (this only has the logic portion, and it's against master, so it
isn't actually a really working patch or anything; also, it doesn't handle
"--not a...b" correctly, whatever that should mean)
---
diff --git a/revision.c b/revision.c
index 6a6952c..c21d332 100644
--- a/revision.c
+++ b/revision.c
@@ -351,6 +351,9 @@ static void add_parents_to_list(struct r
return;
commit->object.flags |= ADDED;
+ if (commit->object.flags & LEFT && commit->objects.flags & RIGHT)
+ commit->object.flags |= UNINTERESTING;
+
/*
* If the commit is uninteresting, don't try to
* prune parents - we want the maximal uninteresting
@@ -781,8 +784,13 @@ int setup_revisions(int argc, const char
struct object *exclude;
struct object *include;
- exclude = get_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
- include = get_reference(revs, next, sha1, flags);
+ if (symmetric) {
+ exclude = get_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
+ include = get_reference(revs, next, sha1, flags);
+ } else {
+ exclude = get_reference(revs, this, from_sha1, flags | LEFT_HALF);
+ include = get_reference(revs, next, sha1, flags | RIGHT_HALF);
+ }
if (!exclude || !include)
die("Invalid revision range %s..%s", arg, next);
diff --git a/revision.h b/revision.h
index 7d85b0f..93421e6 100644
--- a/revision.h
+++ b/revision.h
@@ -9,6 +9,8 @@
#define BOUNDARY (1u<<5)
#define BOUNDARY_SHOW (1u<<6)
#define ADDED (1u<<7) /* Parents already parsed and added? */
+#define LEFT_HALF (1u<<8) /* Reachable from start of dotdotdot */
+#define RIGHT_HALF (1u<<9) /* Reachable from end of dotdotdot */
struct rev_info;
struct log_info;
--
1.2.4
^ permalink raw reply related
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