git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [WIP] Status update on merge-recursive in C
Date: Sun, 09 Jul 2006 01:00:30 -0400	[thread overview]
Message-ID: <1152421230.2103.31.camel@dv> (raw)
In-Reply-To: <Pine.LNX.4.63.0607081840280.29667@wbgn013.biozentrum.uni-wuerzburg.de>

Hello, Dscho!

On Sat, 2006-07-08 at 18:42 +0200, Johannes Schindelin wrote:
> This is just an update for people being interested. Alex and me were
> busy with that project for a few days now. While it has progressed nicely,
> there are quite a couple TODOs in merge-recursive.c, just search for "TODO".

That's great.  Just a few notes regarding the patch.

Why do you list "recur" twice in all_strategies in the git-merge.sh?
The second "recur" should probably be "recursive".

Test for Python in the git-rebase.sh is probably wrong.  "recur" doesn't
need Python - that's the whole point.  In fact, if I build git with
NO_PYTHON, TEST fails in t3401-rebase-partial.sh

Apart from that, the tests pass on i386, x86_64 and PowerPC, all running
Fedora Core 5.

I tries to run sparse of the C files, and it complains about two things
- variable declarations in the middle of the code (allowed by c99 but
not by ANSI C) and incomplete function declarations (no "void").  It's
not C++, let's stick to the C standards.

I'm attaching a patch that fixes everything except variable
declarations.  There are so many of them that it could be done once the
code stabilizes a bit.

It would be great to have a patch that actually removes the old
"recursive" and makes the new strategy "recursive".  I understand it's
the plan, right?

---

 git-merge.sh      |    2 +-
 git-rebase.sh     |    2 +-
 merge-recursive.c |    9 +++++----
 read-cache.c      |    2 +-
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/git-merge.sh b/git-merge.sh
index b26ca14..240e5ee 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -9,7 +9,7 @@ USAGE='[-n] [--no-commit] [--squash] [-s
 LF='
 '
 
-all_strategies='recur recur octopus resolve stupid ours'
+all_strategies='recur recursive octopus resolve stupid ours'
 default_twohead_strategies='recur'
 default_octopus_strategies='octopus'
 no_trivial_merge_strategies='ours'
diff --git a/git-rebase.sh b/git-rebase.sh
index 5d4c7d2..6472970 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -292,7 +292,7 @@ then
 	exit $?
 fi
 
-if test "@@NO_PYTHON@@" && test "$strategy" = "recur"
+if test "@@NO_PYTHON@@" && test "$strategy" = "recursive"
 then
 	die 'The recursive merge strategy currently relies on Python,
 which this installation of git was not configured with.  Please
consider
diff --git a/merge-recursive.c b/merge-recursive.c
index 07a2b38..1cae804 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -61,7 +61,8 @@ static void show_ce_entry(const char *ta
 	fputc('\n', stderr);
 }
 
-static void ls_files() {
+static void ls_files(void)
+{
 	int i;
 	for (i = 0; i < active_nr; i++) {
 		struct cache_entry *ce = active_cache[i];
@@ -207,7 +208,7 @@ static const char *original_index_file;
 static const char *temporary_index_file;
 static int cache_dirty = 0;
 
-static int flush_cache()
+static int flush_cache(void)
 {
 	/* flush temporary index */
 	struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
@@ -331,7 +332,7 @@ #endif
 /*
  * TODO: this can be streamlined by refactoring builtin-write-tree.c
  */
-static struct tree *git_write_tree()
+static struct tree *git_write_tree(void)
 {
 #if 0
 	fprintf(stderr, "GIT_INDEX_FILE='%s' git-write-tree\n",
@@ -467,7 +468,7 @@ static void free_index_entries(struct pa
  * Create a dictionary mapping file names to CacheEntry objects. The
  * dictionary contains one entry for every path with a non-zero stage
entry.
  */
-static struct path_list *get_unmerged()
+static struct path_list *get_unmerged(void)
 {
 	struct path_list *unmerged = xcalloc(1, sizeof(struct path_list));
 	int i;
diff --git a/read-cache.c b/read-cache.c
index f6e1b70..0ef89a9 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -797,7 +797,7 @@ unmap:
 	die("index file corrupt");
 }
 
-int discard_cache()
+int discard_cache(void)
 {
 	int ret;
 	


-- 
Regards,
Pavel Roskin

  reply	other threads:[~2006-07-09  5:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-08 16:42 [WIP] Status update on merge-recursive in C Johannes Schindelin
2006-07-09  5:00 ` Pavel Roskin [this message]
2006-07-09  7:34   ` Junio C Hamano
2006-07-09 14:41   ` Johannes Schindelin
2006-07-27  8:51     ` Junio C Hamano
2006-07-27  9:41       ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1152421230.2103.31.camel@dv \
    --to=proski@gnu.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).