git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH] git-merge: imply --no-ff when --no-commit is given

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 21, 2009, 21:46 UTC
Message-ID
<7viqe81ktx.fsf_-_@alter.siamese.dyndns.org>
In-Reply-To
<7v3a5c2zrr.fsf@alter.siamese.dyndns.org>

Traditionally "git merge --no-commit" meant just that: do not create a new commit even when a merge succeeds. But this leads to confusion when the merged commit is a descendant of the current commit, in which case we succeed the merge by fast-forwarding and without creating a new commit.

Make --no-commit imply --no-ff; --no-commit is a request by the user to tweak the resulting merge and it is clear indication that the user wants to have a merge, even if it is an extra one, to futz with.

There is a test that relies on --no-commit silently fast forwarding; that is obviously broken by this change.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * This is another possibility, which I think is worse than the other one
   in practice but the justification sounds more respectable.
   Unlike the other one, this will still make --no-commit a no-op when you
   are already up-to-date.  As I do not think --no-ff makes much sense in
   my own workflow (either here or dayjob) it is not exactly my itch, but
   I suspect that people who wanted to have --no-ff may want to create an
   extra commit even in such a case; it may be a bug to allow up-to-date
   when --no-ff is given.  Yes, it would make the --no-ff even more insane
   than it already is, but I suspect it would be more consistent with the
   original reasoning of wanting to have the option in the first place,
   namely, to leave the trace of the fact that a "merge" was done at that
   point in the history.
 builtin-merge.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index b6b8428..fa86799 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -874,6 +874,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
 		option_commit = 0;
 	}
 
+	if (!option_commit)
+		allow_fast_forward = 0;
+
 	if (!argc)
 		usage_with_options(builtin_merge_usage,
 			builtin_merge_options);
-- 
1.6.5.1.107.gba912
Previous: Junio C HamanoNext: Clemens Buchacher
Message 22 of 32 in “[RFC] pull/fetch rename”
  1. Thomas RastOct 20, 2009
  2. Wesley J. LandakerOct 20, 2009
  3. Junio C HamanoOct 20, 2009
  4. Thomas RastOct 20, 2009
  5. Junio C HamanoOct 20, 2009
  6. Wesley J. LandakerOct 21, 2009
  7. Junio C HamanoOct 20, 2009
  8. Nanako ShiraishiOct 20, 2009
  9. Thomas RastOct 20, 2009
  10. Daniel BarkalowOct 20, 2009
  11. Björn SteinbrinkOct 21, 2009
  12. Daniel BarkalowOct 21, 2009
  13. Björn SteinbrinkOct 21, 2009
  14. Daniel BarkalowOct 21, 2009
  15. Junio C HamanoOct 21, 2009
  16. Clemens BuchacherOct 21, 2009
  17. modernize fetch/merge/pull examplesClemens Buchacher, Oct 21, 2009
  18. Junio C HamanoOct 21, 2009
  19. git-merge: forbid fast-forward and up-to-date when --no-commit is givenJunio C Hamano, Oct 21, 2009
  20. Nanako ShiraishiOct 22, 2009
  21. Junio C HamanoOct 22, 2009
  22. git-merge: imply --no-ff when --no-commit is givenJunio C Hamano, Oct 21, 2009
  23. Clemens BuchacherOct 22, 2009
  24. Thomas RastOct 22, 2009
  25. Thomas RastOct 22, 2009
  26. Mike HommeyOct 21, 2009
  27. Junio C HamanoOct 21, 2009
  28. Mike HommeyOct 21, 2009
  29. Junio C HamanoOct 21, 2009
  30. Jeff KingOct 21, 2009
  31. Jeff KingOct 21, 2009
  32. Junio C HamanoOct 24, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.