[PATCH] hg-to-git: handle an empty dir in hg by combining git commits

[PATCH] hg-to-git: handle an empty dir in hg by combining git commits

[Mark Drago]

I had a subversion repository which was then converted to hg and now is moving
in to git.  The first commit in the svn repo was just the creation of the empty
directory.  This made its way in to the hg repository fine, but converting from
hg to git would cause an error.  The problem was that hg-to-git.py tries to
commit the change, git-commit fails, and then hg-to-git.py tries to checkout
the new revision and that fails (b/c it was not created).  This may have only
caused an error because it was the first commit in the repository.  If an empty
directory was added in the middle of the repo somewhere things might have
worked out fine.

This patch will detect that there are no changes to commit (using git-status),
and will not perform the commit, but will instead combine the log messages of
that (non-)commit with the next commit.

Signed-off-by: Mark Drago <markdrago@gmail.com>
---
 contrib/hg-to-git/hg-to-git.py |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 6bff49b..06e1b41 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -139,6 +139,7 @@ if not hgvers.has_key("0"):
     os.system('git-init-db')
 
 # loop through every hg changeset
+previous_comment = None
 for cset in range(int(tip) + 1):
 
     # incremental, already seen
@@ -159,6 +160,8 @@ for cset in range(int(tip) + 1):
 
     (fdcomment, filecomment) = tempfile.mkstemp()
     csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag: | grep -v ^branch:' % cset).read().strip()
+    if (previous_comment):
+	csetcomment += previous_comment
     os.write(fdcomment, csetcomment)
     os.close(fdcomment)
 
@@ -181,8 +184,8 @@ for cset in range(int(tip) + 1):
         print 'tag:', tag
     print '-----------------------------------------'
 
-    # checkout the parent if necessary
-    if cset != 0:
+    # checkout the parent if there is a repo to checkout from
+    if hgvers.has_key("0"):
         if hgbranch[str(cset)] == "branch-" + str(cset):
             print 'creating new branch', hgbranch[str(cset)]
             os.system('git-checkout -b %s %s' % (hgbranch[str(cset)], hgvers[parent]))
@@ -210,6 +213,14 @@ for cset in range(int(tip) + 1):
     # delete removed files
     os.system('git-ls-files -x .hg --deleted | git-update-index --remove --stdin')
 
+    # is there something that git will commit (maybe just empty dir was added)
+    stat = os.system('git-status -a')
+    if (stat != 0):
+	print "No changes git notices, will combine log with next commit (maybe empty dir?)"
+	previous_comment = "\n\n--- hg-to-git merged commit ---\n\n" + csetcomment
+	continue
+    previous_comment = None
+
     # commit
     os.system(getgitenv(user, date) + 'git-commit -a -F %s' % filecomment)
     os.unlink(filecomment)
-- 
1.5.2.4

Re: [PATCH] hg-to-git: handle an empty dir in hg by combining git commits

[Junio C Hamano]

Mark Drago <markdrago@gmail.com> writes:

> This patch will detect that there are no changes to commit (using git-status),
> and will not perform the commit, but will instead combine the log messages of
> that (non-)commit with the next commit.

I think a better approach would be to implement --no-tree-change-is-ok
option to git-commit, strictly for use by foreign scm interface scripts
like yours.  It does not usually make sense to record a commit that has
the exact same tree as its sole parent commit and that is why git-commit
prevents you from making that mistake, but when data from foreign scm is
involved, it is a different story.  We are equipped to represent such a
(perhaps insane, perhaps by mistake, or perhaps done on purpose) change
and it is better to represent it bypassing the safety valve for native
use.

[PATCH] git-commit --allow-empty

[Junio C Hamano]

It does not usually make sense to record a commit that has the exact
same tree as its sole parent commit and that is why git-commit prevents
you from making such a mistake, but when data from foreign scm is
involved, it is a different story.  We are equipped to represent such an
(perhaps insane, perhaps by mistake, or perhaps done on purpose) empty
change, and it is better to represent it bypassing the safety valve for
native use.

This is primarily for use by foreign scm interface scripts.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * This is for 'next', on top of an earlier "allow amending '-s ours' merge".

 Documentation/git-commit.txt |    8 +++++++-
 builtin-commit.c             |    5 +++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index d4bfd49..a7ef71f 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -10,7 +10,7 @@ SYNOPSIS
 [verse]
 'git-commit' [-a | --interactive] [-s] [-v] [-u]
 	   [(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
-	   [--no-verify] [-e] [--author <author>]
+	   [--allow-empty] [--no-verify] [-e] [--author <author>]
 	   [--] [[-i | -o ]<file>...]
 
 DESCRIPTION
@@ -89,6 +89,12 @@ OPTIONS
 	This option bypasses the pre-commit hook.
 	See also link:hooks.html[hooks].
 
+--allow-empty::
+	Usually recording a commit that has the exact same tree as its
+	sole parent commit and the command prevents you from making such
+	a mistake.  This option bypasses the safety, and is primarily
+	for use by foreign scm interface scripts.
+
 -e|--edit::
 	The message taken from file with `-F`, command line with
 	`-m`, and from file with `-C` are usually used as the
diff --git a/builtin-commit.c b/builtin-commit.c
index 6c2dc39..e635d99 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -46,7 +46,7 @@ static enum {
 static char *logfile, *force_author, *template_file;
 static char *edit_message, *use_message;
 static int all, edit_flag, also, interactive, only, amend, signoff;
-static int quiet, verbose, untracked_files, no_verify;
+static int quiet, verbose, untracked_files, no_verify, allow_empty;
 
 static int no_edit, initial_commit, in_merge;
 const char *only_include_assumed;
@@ -87,6 +87,7 @@ static struct option builtin_commit_options[] = {
 	OPT_BOOLEAN('n', "no-verify", &no_verify, "bypass pre-commit hook"),
 	OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
 	OPT_BOOLEAN(0, "untracked-files", &untracked_files, "show all untracked files"),
+	OPT_BOOLEAN(0, "allow-empty", &allow_empty, "ok to record an empty change"),
 
 	OPT_END()
 };
@@ -710,7 +711,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 	}
 
 	if (!prepare_log_message(index_file, prefix) && !in_merge &&
-	    !(amend && is_a_merge(head_sha1))) {
+	    !allow_empty && !(amend && is_a_merge(head_sha1))) {
 		run_status(stdout, index_file, prefix);
 		rollback_index_files();
 		unlink(commit_editmsg);
-- 
1.5.3.7-2077-ga07a

[PATCH] git-commit --allow-empty

[Junio C Hamano]

It does not usually make sense to record a commit that has the exact
same tree as its sole parent commit and that is why git-commit prevents
you from making such a mistake, but when data from foreign scm is
involved, it is a different story.  We are equipped to represent such an
(perhaps insane, perhaps by mistake, or perhaps done on purpose) empty
change, and it is better to represent it bypassing the safety valve for
native use.

This is primarily for use by foreign scm interface scripts.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * And this is for 'master'.

 Documentation/git-commit.txt |    8 +++++++-
 git-commit.sh                |   13 ++++++++++---
 t/t7501-commit.sh            |    7 +++++++
 3 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index d4bfd49..a7ef71f 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -10,7 +10,7 @@ SYNOPSIS
 [verse]
 'git-commit' [-a | --interactive] [-s] [-v] [-u]
 	   [(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
-	   [--no-verify] [-e] [--author <author>]
+	   [--allow-empty] [--no-verify] [-e] [--author <author>]
 	   [--] [[-i | -o ]<file>...]
 
 DESCRIPTION
@@ -89,6 +89,12 @@ OPTIONS
 	This option bypasses the pre-commit hook.
 	See also link:hooks.html[hooks].
 
+--allow-empty::
+	Usually recording a commit that has the exact same tree as its
+	sole parent commit and the command prevents you from making such
+	a mistake.  This option bypasses the safety, and is primarily
+	for use by foreign scm interface scripts.
+
 -e|--edit::
 	The message taken from file with `-F`, command line with
 	`-m`, and from file with `-C` are usually used as the
diff --git a/git-commit.sh b/git-commit.sh
index cef76a7..2c4a406 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -74,6 +74,7 @@ trap '
 
 all=
 also=
+allow_empty=f
 interactive=
 only=
 logfile=
@@ -114,6 +115,10 @@ do
 	-a|--a|--al|--all)
 		all=t
 		;;
+	--allo|--allow|--allow-|--allow-e|--allow-em|--allow-emp|\
+	--allow-empt|--allow-empty)
+		allow_empty=t
+		;;
 	--au=*|--aut=*|--auth=*|--autho=*|--author=*)
 		force_author="${1#*=}"
 		;;
@@ -515,9 +520,11 @@ else
 	# we need to check if there is anything to commit
 	run_status >/dev/null
 fi
-case "$?,$PARENTS" in
-0,* | *,-p' '?*-p' '?*)
-	# a merge commit can record the same tree as its parent.
+case "$allow_empty,$?,$PARENTS" in
+t,* | ?,0,* | ?,*,-p' '?*-p' '?*)
+	# an explicit --allow-empty, or a merge commit can record the
+	# same tree as its parent.  Otherwise having commitable paths
+	# is required.
 	;;
 *)
 	rm -f "$GIT_DIR/COMMIT_EDITMSG" "$GIT_DIR/SQUASH_MSG"
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 2e7bcb0..0316ecf 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -256,6 +256,13 @@ test_expect_success 'same tree (single parent)' '
 
 '
 
+test_expect_success 'same tree (single parent) --allow-empty' '
+
+	git commit --allow-empty -m "forced empty" &&
+	git cat-file commit HEAD | grep forced
+
+'
+
 test_expect_success 'same tree (merge and amend merge)' '
 
 	git checkout -b side HEAD^ &&
-- 
1.5.3.7-2077-ga07a

Re: [PATCH] git-commit --allow-empty

[Nicolas Pitre]

On Mon, 3 Dec 2007, Junio C Hamano wrote:

> +--allow-empty::
> +	Usually recording a commit that has the exact same tree as its
> +	sole parent commit and the command prevents you from making such
> +	a mistake.  This option bypasses the safety, and is primarily
> +	for use by foreign scm interface scripts.

The first sentence is rather buggy I would say.


Nicolas

Re: [PATCH] git-commit --allow-empty

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Mon, 3 Dec 2007, Junio C Hamano wrote:
>
>> +--allow-empty::
>> +	Usually recording a commit that has the exact same tree as its
>> +	sole parent commit and the command prevents you from making such
>> +	a mistake.  This option bypasses the safety, and is primarily
>> +	for use by foreign scm interface scripts.
>
> The first sentence is rather buggy I would say.

It indeed is.  Sorry.

Re: [PATCH] hg-to-git: handle an empty dir in hg by combining git commits

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Mark Drago <markdrago@gmail.com> writes:
>
>> This patch will detect that there are no changes to commit (using git-status),
>> and will not perform the commit, but will instead combine the log messages of
>> that (non-)commit with the next commit.
>
> I think a better approach would be to implement --no-tree-change-is-ok
> option to git-commit, strictly for use by foreign scm interface scripts
> like yours.  It does not usually make sense to record a commit that has
> the exact same tree as its sole parent commit and that is why git-commit
> prevents you from making that mistake, but when data from foreign scm is
> involved, it is a different story.  We are equipped to represent such a
> (perhaps insane, perhaps by mistake, or perhaps done on purpose) change
> and it is better to represent it bypassing the safety valve for native
> use.

So I did "git commit --allow-empty".  With that, perhaps the following
will fix the issue?

I won't be commiting this myself until I hear a positive Ack.

---
 contrib/hg-to-git/hg-to-git.py |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 7a1c3e4..9befb92 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -211,7 +211,7 @@ for cset in range(int(tip) + 1):
     os.system('git-ls-files -x .hg --deleted | git-update-index --remove --stdin')
 
     # commit
-    os.system(getgitenv(user, date) + 'git-commit -a -F %s' % filecomment)
+    os.system(getgitenv(user, date) + 'git commit --allow-empty -a -F %s' % filecomment)
     os.unlink(filecomment)
 
     # tag

Re: [PATCH] hg-to-git: handle an empty dir in hg by combining git commits

[Mark Drago]

On Dec 5, 2007 2:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Mark Drago <markdrago@gmail.com> writes:
> >
> >> This patch will detect that there are no changes to commit (using git-status),
> >> and will not perform the commit, but will instead combine the log messages of
> >> that (non-)commit with the next commit.
> >
> > I think a better approach would be to implement --no-tree-change-is-ok
> > option to git-commit, strictly for use by foreign scm interface scripts
> > like yours.  It does not usually make sense to record a commit that has
> > the exact same tree as its sole parent commit and that is why git-commit
> > prevents you from making that mistake, but when data from foreign scm is
> > involved, it is a different story.  We are equipped to represent such a
> > (perhaps insane, perhaps by mistake, or perhaps done on purpose) change
> > and it is better to represent it bypassing the safety valve for native
> > use.
>
> So I did "git commit --allow-empty".  With that, perhaps the following
> will fix the issue?
>
> I won't be commiting this myself until I hear a positive Ack.

I gave this a test and it works perfectly well.  Commit away.

Thanks,
Mark.

> ---
>  contrib/hg-to-git/hg-to-git.py |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
> index 7a1c3e4..9befb92 100755
> --- a/contrib/hg-to-git/hg-to-git.py
> +++ b/contrib/hg-to-git/hg-to-git.py
> @@ -211,7 +211,7 @@ for cset in range(int(tip) + 1):
>      os.system('git-ls-files -x .hg --deleted | git-update-index --remove --stdin')
>
>      # commit
> -    os.system(getgitenv(user, date) + 'git-commit -a -F %s' % filecomment)
> +    os.system(getgitenv(user, date) + 'git commit --allow-empty -a -F %s' % filecomment)
>      os.unlink(filecomment)
>
>      # tag
>