git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* git-merge: --no-commit is not respected on a fresh repository
@ 2024-04-03 13:26 Jasmin Oster
  2024-04-03 17:29 ` Junio C Hamano
  0 siblings, 1 reply; 2+ messages in thread
From: Jasmin Oster @ 2024-04-03 13:26 UTC (permalink / raw)
  To: git@vger.kernel.org

## What did you do before the bug happened? (Steps to reproduce your issue)

When trying to perform a subtree merge, especially following the blog 
post on https://nuclearsquid.com/writings/subtree-merging-and-you/,
I noticed that Git does not respect the --no-commit option if the 
repository does not have a history.

1. Create a new repository: $ git init
2. Add a remote: $ git remote add foo ../<path-to-another-repo>
3. Fetch everything: $ git fetch --all
4. Initiate a subtree merge: $ git merge -s our --no-commit foo/main

## What did you expect to happen? (Expected behavior)

The repository should've been in the "merging" state, in order to 
rewrite the paths using:

$ git read-tree --prefix=/project/ -u foo/main

It's only a minor annoyance that can be fixed by adding an empty commit 
in advance of performing the merge, yet it took me some minutes to 
figure out why Git does not behave as intended.

## What happened instead? (Actual behavior)

A merge commit was created.

## What's different between what you expected and what actually happened?

Said merge commit, even though the `--no-commit` option was set.

[System Info]
git version:
git version 2.44.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.7.10-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Mar 18 
18:56:52 UTC 2024 x86_64
compiler info: gnuc: 13.2
libc info: glibc: 2.38
$SHELL (typically, interactive shell): /usr/bin/fish

-- 
Mit freundlichen Grüßen / kind regards

*Jasmin Oster*
Software Developer

ANEXIA Internetdienstleistungs GmbH

E-Mail: JOster@anexia.com <mailto:DName@anexia.com>
Web: anexia.com <https://anexia.com/>

Anschrift Hauptsitz Klagenfurt: Feldkirchner Straße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT 
U63216601

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: git-merge: --no-commit is not respected on a fresh repository
  2024-04-03 13:26 git-merge: --no-commit is not respected on a fresh repository Jasmin Oster
@ 2024-04-03 17:29 ` Junio C Hamano
  0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2024-04-03 17:29 UTC (permalink / raw)
  To: Jasmin Oster; +Cc: git@vger.kernel.org

Jasmin Oster <JOster@anexia.com> writes:

> 1. Create a new repository: $ git init
> 2. Add a remote: $ git remote add foo ../<path-to-another-repo>
> 3. Fetch everything: $ git fetch --all
> 4. Initiate a subtree merge: $ git merge -s our --no-commit foo/main

This is expected.  We are not creating any new commit, so it is
following the --no-commit option to the letter.  Obviously it is
different from what you expected to see, though ;-)

The "merge into void" first came to "git pull $URL $branch" (no
other options) where people tried to pull into a freshly created
repository, where it was very clear that they wanted to have a copy
of the upstream branch.  The "git pull" implementation of the
"pulling into void" feature forgot that curious users may give
"--no-commit", and just always fast-forwarded to the merged commit
without checking if such an option was given.

The behaviour you are seeing was inherited into "git merge".  It
also always fast-forwards to the merged commit, ignoring the option.

In either case, there is no new commit created.  The history you are
seeing is the exact history of the upstream.  If you want to
dissociate your history from theirs and start your history anew:

    $ git merge foo/main
    $ git checkout --orphan master

would give you an unborn branch "master", with the merge result in
the working tree and in the index, without any history behind it.
If you wanted to, you can then rename it to main from this state
with:

    $ git branch -M master main

We could make it more explicit with a patch like the following, but
it probably is not worth it.  I dunno.

 builtin/merge.c | 2 ++
 builtin/pull.c  | 2 ++
 2 files changed, 4 insertions(+)

diff --git c/builtin/merge.c w/builtin/merge.c
index 1cbd6a899c..1c3165e99a 100644
--- c/builtin/merge.c
+++ w/builtin/merge.c
@@ -1434,6 +1434,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
 		struct object_id *remote_head_oid;
 		if (squash)
 			die(_("Squash commit into empty head not supported yet"));
+		if (!option_commit)
+			die(_("--no-commit into empty head not supported"));
 		if (fast_forward == FF_NO)
 			die(_("Non-fast-forward commit does not make sense into "
 			    "an empty head"));
diff --git c/builtin/pull.c w/builtin/pull.c
index 72cbb76d52..98c11ecc55 100644
--- c/builtin/pull.c
+++ w/builtin/pull.c
@@ -1097,6 +1097,8 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 	if (is_null_oid(&orig_head)) {
 		if (merge_heads.nr > 1)
 			die(_("Cannot merge multiple branches into empty head."));
+		if (opt_commit && !strcmp("--no-commit", opt_commit))
+			die(_("--no-commit into empty head not supported"));
 		ret = pull_into_void(merge_heads.oid, &curr_head);
 		goto cleanup;
 	}

^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-04-03 17:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-03 13:26 git-merge: --no-commit is not respected on a fresh repository Jasmin Oster
2024-04-03 17:29 ` Junio C Hamano

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).