threads / patch / 60423

patchmerge-file: add an option to process object IDs

Subject: [PATCH 1/1] merge-file: add an option to process object IDs

## tl;dr

34 messages between Oct 24, 2023 and Nov 2, 2023. Diffs are folded; open one to read it.

replies: 33people: 7as markdown or json

brian m. carlson· Oct 24, 2023, 19:56 UTC · lore

[PATCH 0/1] Object ID support for git merge-file

This series introduces an --object-id option to git merge-file such that, instead of reading and writing from files on the system, it reads from and writes to the object store using blobs. This is in use at GitHub to produce conflict diffs when a merge fails, and it seems generally useful, so I'm sending it here.

The only tricky piece is the fact that we have to special-case the empty blob since otherwise it isn't handled correctly.

brian m. carlson (1):
  merge-file: add an option to process object IDs
 Documentation/git-merge-file.txt | 20 +++++++++++
 builtin/merge-file.c             | 58 +++++++++++++++++++++++---------
 t/t6403-merge-file.sh            | 58 ++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+), 16 deletions(-)
brian m. carlson· Oct 24, 2023, 19:56 UTC · re: brian m. carlson · lore
From: "brian m. carlson" <bk2204@github.com>

git merge-file knows how to merge files on the file system already. It would be helpful, however, to allow it to also merge single blobs. Teach it an `--object-id` option which means that its arguments are object IDs and not files to allow it to do so.

Since we obviously won't be writing the data to the first argument, either write to the object store and print the object ID, or honor the -p argument and print it to standard out.

We handle the empty blob specially since read_mmblob doesn't read it directly, instead throwing an error, and otherwise users cannot specify an empty ancestor.

Signed-off-by: brian m. carlson <bk2204@github.com>
---
 Documentation/git-merge-file.txt | 20 +++++++++++
 builtin/merge-file.c             | 58 +++++++++++++++++++++++---------
 t/t6403-merge-file.sh            | 58 ++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+), 16 deletions(-)
Show changes to 3 files +120 −16

Documentation/git-merge-file.txt, builtin/merge-file.c, t/t6403-merge-file.sh

diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
index 7e9093fab6..45460f3916 100644
--- a/Documentation/git-merge-file.txt
+++ b/Documentation/git-merge-file.txt
@@ -12,6 +12,9 @@ SYNOPSIS
 'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
 	[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
 	[--[no-]diff3] <current-file> <base-file> <other-file>
+'git merge-file' --object-id [-L <current-name> [-L <base-name> [-L <other-name>]]]
+	[--ours|--theirs|--union] [-q|--quiet] [--marker-size=<n>]
+	[--[no-]diff3] <current-oid> <base-oid> <other-oid>
 
 
 DESCRIPTION
@@ -40,6 +43,10 @@ however, these conflicts are resolved favouring lines from `<current-file>`,
 lines from `<other-file>`, or lines from both respectively.  The length of the
 conflict markers can be given with the `--marker-size` option.
 
+If `--object-id` is specified, exactly the same behavior occurs, except that
+instead of specifying what to merge as files, it is specified as a list of
+object IDs referring to blobs.
+
 The exit value of this program is negative on error, and the number of
 conflicts otherwise (truncated to 127 if there are more than that many
 conflicts). If the merge was clean, the exit value is 0.
@@ -52,6 +59,14 @@ linkgit:git[1].
 OPTIONS
 -------
 
+--object-id::
+	Specify the contents to merge as blobs in the current repository instead of
+	files.  In this case, the operation must take place within a valid repository.
++
+If the `-p` option is specified, the merged file (including conflicts, if any)
+goes to standard output as normal; otherwise, the merged file is written to the
+object store and the object ID of its blob is written to standard output.
+
 -L <label>::
 	This option may be given up to three times, and
 	specifies labels to be used in place of the
@@ -93,6 +108,11 @@ EXAMPLES
 	merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
 	`a` and `c` instead of `tmp/a123` and `tmp/c345`.
 
+`git merge-file -p --object-id abc1234 def567 890abcd`::
+
+	combines the changes of the blob abc1234 and 890abcd since def567,
+	tries to merge them and writes the result to standard output
+
 GIT
 ---
 Part of the linkgit:git[1] suite
diff --git a/builtin/merge-file.c b/builtin/merge-file.c
index d7eb4c6540..d308434b8e 100644
--- a/builtin/merge-file.c
+++ b/builtin/merge-file.c
@@ -1,5 +1,8 @@
 #include "builtin.h"
 #include "abspath.h"
+#include "hex.h"
+#include "object-name.h"
+#include "object-store.h"
 #include "config.h"
 #include "gettext.h"
 #include "setup.h"
@@ -31,10 +34,11 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 	mmfile_t mmfs[3] = { 0 };
 	mmbuffer_t result = { 0 };
 	xmparam_t xmp = { 0 };
-	int ret = 0, i = 0, to_stdout = 0;
+	int ret = 0, i = 0, to_stdout = 0, object_id = 0;
 	int quiet = 0;
 	struct option options[] = {
 		OPT_BOOL('p', "stdout", &to_stdout, N_("send results to standard output")),
+		OPT_BOOL(0,   "object-id", &object_id, N_("use object IDs instead of filenames")),
 		OPT_SET_INT(0, "diff3", &xmp.style, N_("use a diff3 based merge"), XDL_MERGE_DIFF3),
 		OPT_SET_INT(0, "zdiff3", &xmp.style, N_("use a zealous diff3 based merge"),
 				XDL_MERGE_ZEALOUS_DIFF3),
@@ -71,8 +75,12 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 			return error_errno("failed to redirect stderr to /dev/null");
 	}
 
+	if (object_id)
+		setup_git_directory();
+
 	for (i = 0; i < 3; i++) {
 		char *fname;
+		struct object_id oid;
 		mmfile_t *mmf = mmfs + i;
 
 		if (!names[i])
@@ -80,12 +88,21 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 
 		fname = prefix_filename(prefix, argv[i]);
 
-		if (read_mmfile(mmf, fname))
+		if (object_id) {
+			if (repo_get_oid(the_repository, argv[i], &oid))
+				ret = -1;
+			else if (!oideq(&oid, the_hash_algo->empty_blob))
+				read_mmblob(mmf, &oid);
+			else
+				read_mmfile(mmf, "/dev/null");
+		} else if (read_mmfile(mmf, fname)) {
 			ret = -1;
-		else if (mmf->size > MAX_XDIFF_SIZE ||
-			 buffer_is_binary(mmf->ptr, mmf->size))
+		}
+		if (ret != -1 && (mmf->size > MAX_XDIFF_SIZE ||
+		    buffer_is_binary(mmf->ptr, mmf->size))) {
 			ret = error("Cannot merge binary files: %s",
 				    argv[i]);
+		}
 
 		free(fname);
 		if (ret)
@@ -99,20 +116,29 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 	ret = xdl_merge(mmfs + 1, mmfs + 0, mmfs + 2, &xmp, &result);
 
 	if (ret >= 0) {
-		const char *filename = argv[0];
-		char *fpath = prefix_filename(prefix, argv[0]);
-		FILE *f = to_stdout ? stdout : fopen(fpath, "wb");
+		if (object_id && !to_stdout) {
+			struct object_id oid;
+			if (result.size)
+				write_object_file(result.ptr, result.size, OBJ_BLOB, &oid);
+			else
+				oidcpy(&oid, the_hash_algo->empty_blob);
+			printf("%s\n", oid_to_hex(&oid));
+		} else {
+			const char *filename = argv[0];
+			char *fpath = prefix_filename(prefix, argv[0]);
+			FILE *f = to_stdout ? stdout : fopen(fpath, "wb");
 
-		if (!f)
-			ret = error_errno("Could not open %s for writing",
-					  filename);
-		else if (result.size &&
-			 fwrite(result.ptr, result.size, 1, f) != 1)
-			ret = error_errno("Could not write to %s", filename);
-		else if (fclose(f))
-			ret = error_errno("Could not close %s", filename);
+			if (!f)
+				ret = error_errno("Could not open %s for writing",
+						  filename);
+			else if (result.size &&
+				 fwrite(result.ptr, result.size, 1, f) != 1)
+				ret = error_errno("Could not write to %s", filename);
+			else if (fclose(f))
+				ret = error_errno("Could not close %s", filename);
+			free(fpath);
+		}
 		free(result.ptr);
-		free(fpath);
 	}
 
 	if (ret > 127)
diff --git a/t/t6403-merge-file.sh b/t/t6403-merge-file.sh
index 1a7082323d..2c92209eca 100755
--- a/t/t6403-merge-file.sh
+++ b/t/t6403-merge-file.sh
@@ -65,11 +65,30 @@ test_expect_success 'merge with no changes' '
 	test_cmp test.txt orig.txt
 '
 
+test_expect_success 'merge with no changes with --object-id' '
+	git add orig.txt &&
+	git merge-file -p --object-id :orig.txt :orig.txt :orig.txt >actual &&
+	test_cmp actual orig.txt
+'
+
 test_expect_success "merge without conflict" '
 	cp new1.txt test.txt &&
 	git merge-file test.txt orig.txt new2.txt
 '
 
+test_expect_success 'merge without conflict with --object-id' '
+	git add orig.txt new2.txt &&
+	git merge-file --object-id :orig.txt :orig.txt :new2.txt >actual &&
+	git rev-parse :new2.txt >expected &&
+	test_cmp actual expected
+'
+
+test_expect_success 'can accept object ID with --object-id' '
+	git merge-file --object-id $(test_oid empty_blob) $(test_oid empty_blob) :new2.txt >actual &&
+	git rev-parse :new2.txt >expected &&
+	test_cmp actual expected
+'
+
 test_expect_success 'works in subdirectory' '
 	mkdir dir &&
 	cp new1.txt dir/a.txt &&
@@ -138,6 +157,31 @@ test_expect_success "expected conflict markers" '
 	test_cmp expect.txt test.txt
 '
 
+test_expect_success "merge with conflicts with --object-id" '
+	git add backup.txt orig.txt new3.txt &&
+	test_must_fail git merge-file -p --object-id :backup.txt :orig.txt :new3.txt >actual &&
+	sed -e "s/<< test.txt/<< :backup.txt/" \
+	    -e "s/>> new3.txt/>> :new3.txt/" \
+	    expect.txt >expect &&
+	test_cmp expect actual &&
+	test_must_fail git merge-file --object-id :backup.txt :orig.txt :new3.txt >oid &&
+	git cat-file blob "$(cat oid)" >actual &&
+	test_cmp expect actual
+'
+
+test_expect_success "merge with conflicts with --object-id with labels" '
+	git add backup.txt orig.txt new3.txt &&
+	test_must_fail git merge-file -p --object-id \
+		-L test.txt -L orig.txt -L new3.txt \
+		:backup.txt :orig.txt :new3.txt >actual &&
+	test_cmp expect.txt actual &&
+	test_must_fail git merge-file --object-id \
+		-L test.txt -L orig.txt -L new3.txt \
+		:backup.txt :orig.txt :new3.txt >oid &&
+	git cat-file blob "$(cat oid)" >actual &&
+	test_cmp expect.txt actual
+'
+
 test_expect_success "merge conflicting with --ours" '
 	cp backup.txt test.txt &&
 
@@ -256,6 +300,14 @@ test_expect_success 'binary files cannot be merged' '
 	grep "Cannot merge binary files" merge.err
 '
 
+test_expect_success 'binary files cannot be merged with --object-id' '
+	cp "$TEST_DIRECTORY"/test-binary-1.png . &&
+	git add orig.txt new1.txt test-binary-1.png &&
+	test_must_fail git merge-file --object-id \
+		:orig.txt :test-binary-1.png :new1.txt 2> merge.err &&
+	grep "Cannot merge binary files" merge.err
+'
+
 test_expect_success 'MERGE_ZEALOUS simplifies non-conflicts' '
 	sed -e "s/deerit.\$/deerit;/" -e "s/me;\$/me./" <new5.txt >new6.txt &&
 	sed -e "s/deerit.\$/deerit,/" -e "s/me;\$/me,/" <new5.txt >new7.txt &&
@@ -389,4 +441,10 @@ test_expect_success 'conflict sections match existing line endings' '
 	test $(tr "\015" Q <nolf.txt | grep "^[<=>].*Q$" | wc -l) = 0
 '
 
+test_expect_success '--object-id fails without repository' '
+	empty="$(test_oid empty_blob)" &&
+	nongit test_must_fail git merge-file --object-id $empty $empty $empty 2>err &&
+	grep "not a git repository" err
+'
+
 test_done
Eric Sunshine· Oct 24, 2023, 20:12 UTC · re: brian m. carlson · lore

Re: [PATCH 1/1] merge-file: add an option to process object IDs

On Tue, Oct 24, 2023 at 3:58 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 25 quoted lines
> git merge-file knows how to merge files on the file system already.  It
> would be helpful, however, to allow it to also merge single blobs.
> Teach it an `--object-id` option which means that its arguments are
> object IDs and not files to allow it to do so.
>
> Since we obviously won't be writing the data to the first argument,
> either write to the object store and print the object ID, or honor the
> -p argument and print it to standard out.
>
> We handle the empty blob specially since read_mmblob doesn't read it
> directly, instead throwing an error, and otherwise users cannot specify
> an empty ancestor.
>
> Signed-off-by: brian m. carlson <bk2204@github.com>
> ---
> diff --git a/builtin/merge-file.c b/builtin/merge-file.c
> @@ -99,20 +116,29 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
>         if (ret >= 0) {
> -               const char *filename = argv[0];
> -               char *fpath = prefix_filename(prefix, argv[0]);
> -               FILE *f = to_stdout ? stdout : fopen(fpath, "wb");
> +               if (object_id && !to_stdout) {
> +                       struct object_id oid;
> +                       if (result.size)
> +                               write_object_file(result.ptr, result.size, OBJ_BLOB, &oid);

Should this be caring about errors by checking the return value of write_object_file()?

Show 13 quoted lines
> +               } else {
> +                       const char *filename = argv[0];
> +                       char *fpath = prefix_filename(prefix, argv[0]);
> +                       FILE *f = to_stdout ? stdout : fopen(fpath, "wb");
> +                       if (!f)
> +                               ret = error_errno("Could not open %s for writing",
> +                                                 filename);
> +                       else if (result.size &&
> +                                fwrite(result.ptr, result.size, 1, f) != 1)
> +                               ret = error_errno("Could not write to %s", filename);
> +                       else if (fclose(f))
> +                               ret = error_errno("Could not close %s", filename);
> +                       free(fpath);
 The non-"object-id" case cares about errors.
brian m. carlson· Oct 24, 2023, 21:23 UTC · re: Eric Sunshine · lore

Re: [PATCH 1/1] merge-file: add an option to process object IDs

On 2023-10-24 at 20:12:52, Eric Sunshine wrote:
Show 30 quoted lines
> On Tue, Oct 24, 2023 at 3:58 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > git merge-file knows how to merge files on the file system already.  It
> > would be helpful, however, to allow it to also merge single blobs.
> > Teach it an `--object-id` option which means that its arguments are
> > object IDs and not files to allow it to do so.
> >
> > Since we obviously won't be writing the data to the first argument,
> > either write to the object store and print the object ID, or honor the
> > -p argument and print it to standard out.
> >
> > We handle the empty blob specially since read_mmblob doesn't read it
> > directly, instead throwing an error, and otherwise users cannot specify
> > an empty ancestor.
> >
> > Signed-off-by: brian m. carlson <bk2204@github.com>
> > ---
> > diff --git a/builtin/merge-file.c b/builtin/merge-file.c
> > @@ -99,20 +116,29 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
> >         if (ret >= 0) {
> > -               const char *filename = argv[0];
> > -               char *fpath = prefix_filename(prefix, argv[0]);
> > -               FILE *f = to_stdout ? stdout : fopen(fpath, "wb");
> > +               if (object_id && !to_stdout) {
> > +                       struct object_id oid;
> > +                       if (result.size)
> > +                               write_object_file(result.ptr, result.size, OBJ_BLOB, &oid);
> 
> Should this be caring about errors by checking the return value of
> write_object_file()?

Probably so. I think I saw write_object_file_prepare returned void and misinterpreted that as write_object_file returning void.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Elijah Newren· Oct 29, 2023, 06:17 UTC · re: brian m. carlson · lore

Re: [PATCH 1/1] merge-file: add an option to process object IDs

Hi,
Overall, looks good.  Just a couple questions...

On Tue, Oct 24, 2023 at 12:58 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

>
> From: "brian m. carlson" <bk2204@github.com>
>
[...]
Show 9 quoted lines
> --- a/Documentation/git-merge-file.txt
> +++ b/Documentation/git-merge-file.txt
> @@ -12,6 +12,9 @@ SYNOPSIS
>  'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
>         [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
>         [--[no-]diff3] <current-file> <base-file> <other-file>
> +'git merge-file' --object-id [-L <current-name> [-L <base-name> [-L <other-name>]]]
> +       [--ours|--theirs|--union] [-q|--quiet] [--marker-size=<n>]
> +       [--[no-]diff3] <current-oid> <base-oid> <other-oid>

Why was the `[-p|--stdout]` option removed in the second synopsis? Elsewhere you explicitly call it out as a possibility to be used with --object-id.

Also, why the extra synopsis instead of just adding a `[--object-id]` option to the previous one?

[...]
Show 12 quoted lines
> @@ -80,12 +88,21 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
>
>                 fname = prefix_filename(prefix, argv[i]);
>
> -               if (read_mmfile(mmf, fname))
> +               if (object_id) {
> +                       if (repo_get_oid(the_repository, argv[i], &oid))
> +                               ret = -1;
> +                       else if (!oideq(&oid, the_hash_algo->empty_blob))
> +                               read_mmblob(mmf, &oid);
> +                       else
> +                               read_mmfile(mmf, "/dev/null");

Does "/dev/null" have any portability considerations? (I really don't know; just curious.)

Phillip Wood· Oct 29, 2023, 10:12 UTC · re: Elijah Newren · lore

Re: [PATCH 1/1] merge-file: add an option to process object IDs

Hi brian
I agree with everything Elijah said, I just have one more comment
Show 8 quoted lines
>> @@ -80,12 +88,21 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
>>
>>                  fname = prefix_filename(prefix, argv[i]);
>>
>> -               if (read_mmfile(mmf, fname))
>> +               if (object_id) {
>> +                       if (repo_get_oid(the_repository, argv[i], &oid))
>> +                               ret = -1;
It would be nice to print an error message here
	ret = error("object '%s' does not exist", argv[i]);

none of the existing error messages are marked for translation so I've left this untranslated as well.

Best Wishes
Phillip
brian m. carlson· Oct 30, 2023, 16:14 UTC · re: Phillip Wood · lore

Re: [PATCH 1/1] merge-file: add an option to process object IDs

On 2023-10-29 at 10:12:57, Phillip Wood wrote:
> It would be nice to print an error message here
> 
> 	ret = error("object '%s' does not exist", argv[i]);
Good point.  I'll include that in my reroll.
> none of the existing error messages are marked for translation so I've left
> this untranslated as well.

I've opted to make them translatable here because I think that's for the best.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
brian m. carlson· Oct 29, 2023, 14:18 UTC · re: Elijah Newren · lore

Re: [PATCH 1/1] merge-file: add an option to process object IDs

On 2023-10-29 at 06:17:09, Elijah Newren wrote:
Show 23 quoted lines
> Hi,
> 
> Overall, looks good.  Just a couple questions...
> 
> On Tue, Oct 24, 2023 at 12:58 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> >
> > From: "brian m. carlson" <bk2204@github.com>
> >
> [...]
> > --- a/Documentation/git-merge-file.txt
> > +++ b/Documentation/git-merge-file.txt
> > @@ -12,6 +12,9 @@ SYNOPSIS
> >  'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
> >         [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
> >         [--[no-]diff3] <current-file> <base-file> <other-file>
> > +'git merge-file' --object-id [-L <current-name> [-L <base-name> [-L <other-name>]]]
> > +       [--ours|--theirs|--union] [-q|--quiet] [--marker-size=<n>]
> > +       [--[no-]diff3] <current-oid> <base-oid> <other-oid>
> 
> Why was the `[-p|--stdout]` option removed in the second synopsis?
> Elsewhere you explicitly call it out as a possibility to be used with
> --object-id.

Originally because it implied `-p`, but I changed that to write into the object store. I'll restore it.

> Also, why the extra synopsis instead of just adding a `[--object-id]`
> option to the previous one?

Because there's a relevant difference: the former has <current-file>, <base-file>, and <other-file>, and the latter has the -oid versions.

> Does "/dev/null" have any portability considerations?  (I really don't
> know; just curious.)

We already use it elsewhere in the codebase, so I assume it works. We also have a test for that case and it worked in CI, so it's probably fine.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Elijah Newren· Oct 30, 2023, 16:39 UTC · re: brian m. carlson · lore

Re: [PATCH 1/1] merge-file: add an option to process object IDs

Hi,

On Sun, Oct 29, 2023 at 7:18 AM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 34 quoted lines
>
> On 2023-10-29 at 06:17:09, Elijah Newren wrote:
> > Hi,
> >
> > Overall, looks good.  Just a couple questions...
> >
> > On Tue, Oct 24, 2023 at 12:58 PM brian m. carlson
> > <sandals@crustytoothpaste.net> wrote:
> > >
> > > From: "brian m. carlson" <bk2204@github.com>
> > >
> > [...]
> > > --- a/Documentation/git-merge-file.txt
> > > +++ b/Documentation/git-merge-file.txt
> > > @@ -12,6 +12,9 @@ SYNOPSIS
> > >  'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
> > >         [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
> > >         [--[no-]diff3] <current-file> <base-file> <other-file>
> > > +'git merge-file' --object-id [-L <current-name> [-L <base-name> [-L <other-name>]]]
> > > +       [--ours|--theirs|--union] [-q|--quiet] [--marker-size=<n>]
> > > +       [--[no-]diff3] <current-oid> <base-oid> <other-oid>
> >
> > Why was the `[-p|--stdout]` option removed in the second synopsis?
> > Elsewhere you explicitly call it out as a possibility to be used with
> > --object-id.
>
> Originally because it implied `-p`, but I changed that to write into the
> object store.  I'll restore it.
>
> > Also, why the extra synopsis instead of just adding a `[--object-id]`
> > option to the previous one?
>
> Because there's a relevant difference: the former has <current-file>,
> <base-file>, and <other-file>, and the latter has the -oid versions.

Ah, I looked over it a couple times and just kept missing that difference. Thanks for pointing it out.

Show 7 quoted lines
>
> > Does "/dev/null" have any portability considerations?  (I really don't
> > know; just curious.)
>
> We already use it elsewhere in the codebase, so I assume it works.  We
> also have a test for that case and it worked in CI, so it's probably
> fine.
Seems reasonable to me; thanks.
Elijah Newren· Oct 29, 2023, 06:24 UTC · re: brian m. carlson · lore

Re: [PATCH 0/1] Object ID support for git merge-file

On Tue, Oct 24, 2023 at 12:58 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

>
> This series introduces an --object-id option to git merge-file such
> that, instead of reading and writing from files on the system, it reads
> from and writes to the object store using blobs.
This seems like a reasonable capability to want from such a plumbing command.
> This is in use at
> GitHub to produce conflict diffs when a merge fails, and it seems
> generally useful, so I'm sending it here.

But...wouldn't you already have the conflicts generated when doing the merge and learning that it fails? Why would you need to generate them again?

(Also, generating them again may risk getting names munged for conflict markers in edge cases involving renames.)

That said, even if I have questions about your particular usecase, I think the feature you are submitting here makes sense independently.

I left a few minor questions on the patch itself, but overall it looks good to me.

Phillip Wood· Oct 29, 2023, 10:15 UTC · re: Elijah Newren · lore

Re: [PATCH 0/1] Object ID support for git merge-file

On 29/10/2023 06:24, Elijah Newren wrote:
Show 8 quoted lines
> On Tue, Oct 24, 2023 at 12:58 PM brian m. carlson
>> This is in use at
>> GitHub to produce conflict diffs when a merge fails, and it seems
>> generally useful, so I'm sending it here.
> 
> But...wouldn't you already have the conflicts generated when doing the
> merge and learning that it fails?  Why would you need to generate them
> again?

I was surprised by this as well, but as you say this seems like a useful addition independent of any specific use at GitHub.

Best Wishes
Phillip
Taylor Blau· Oct 30, 2023, 15:54 UTC · re: Elijah Newren · lore

Re: [PATCH 0/1] Object ID support for git merge-file

On Sat, Oct 28, 2023 at 11:24:06PM -0700, Elijah Newren wrote:
Show 8 quoted lines
> On Tue, Oct 24, 2023 at 12:58 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> >
> > This series introduces an --object-id option to git merge-file such
> > that, instead of reading and writing from files on the system, it reads
> > from and writes to the object store using blobs.
>
> This seems like a reasonable capability to want from such a plumbing command.
Agreed.
Show 7 quoted lines
> > This is in use at
> > GitHub to produce conflict diffs when a merge fails, and it seems
> > generally useful, so I'm sending it here.
>
> But...wouldn't you already have the conflicts generated when doing the
> merge and learning that it fails?  Why would you need to generate them
> again?

brian would know better than I do, but I believe the reason is because the "attempt this merge" RPC is handled separately from the "show me the merge conflict(s) at xyz path". Those probably could be combined (obviating the need for this patch), but doing so is probably rather complicated.

Since this feature is generally useful for callers that haven't already completed a tree-level merge and really just care about the result of merging a single path, I don't have any objections here.

Thanks, Taylor

brian m. carlson· Oct 30, 2023, 16:24 UTC · re: Taylor Blau · lore

Re: [PATCH 0/1] Object ID support for git merge-file

On 2023-10-30 at 15:54:14, Taylor Blau wrote:
Show 10 quoted lines
> On Sat, Oct 28, 2023 at 11:24:06PM -0700, Elijah Newren wrote:
> > But...wouldn't you already have the conflicts generated when doing the
> > merge and learning that it fails?  Why would you need to generate them
> > again?
> 
> brian would know better than I do, but I believe the reason is because
> the "attempt this merge" RPC is handled separately from the "show me the
> merge conflict(s) at xyz path". Those probably could be combined
> (obviating the need for this patch), but doing so is probably rather
> complicated.

That's correct. They could in theory happen at different times, which is why they're not linked.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Elijah Newren· Oct 30, 2023, 17:14 UTC · re: brian m. carlson · lore

Re: [PATCH 0/1] Object ID support for git merge-file

On Mon, Oct 30, 2023 at 9:24 AM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 15 quoted lines
>
> On 2023-10-30 at 15:54:14, Taylor Blau wrote:
> > On Sat, Oct 28, 2023 at 11:24:06PM -0700, Elijah Newren wrote:
> > > But...wouldn't you already have the conflicts generated when doing the
> > > merge and learning that it fails?  Why would you need to generate them
> > > again?
> >
> > brian would know better than I do, but I believe the reason is because
> > the "attempt this merge" RPC is handled separately from the "show me the
> > merge conflict(s) at xyz path". Those probably could be combined
> > (obviating the need for this patch), but doing so is probably rather
> > complicated.
>
> That's correct.  They could in theory happen at different times, which
> is why they're not linked.

Maybe this is digging a little into "historical reasons" too much, but this still seems a little funny. If they happen at different times, you still need multiple pieces of information remembered from the merge operation in order for git-merge-file to be able to regenerate the conflict correctly in general. In particular, you need the OIDs and the filenames. Trying to regenerate a conflict without remembering those from the merge step would only work for common cases, but would be problematic in the face of either renames being involved or recursive merges or both. And if you need to remember information from the merge step, then why not remember the actual conflicts (or at least the tree OID generated by the merge operation, which has the conflicts embedded within it)?

I know, I know, there's probably just historical cruft that needs cleaning up, and I don't think any of this matters to the patch at hand since it's independently useful. It just sounds like a system has been set up that has some rough edge cases caused by a poor splitting.

> --
> brian m. carlson (he/him or they/them)
> Toronto, Ontario, CA
brian m. carlson· Oct 30, 2023, 16:26 UTC · re: brian m. carlson · lore

[PATCH v2 0/1] Object ID support for git merge-file

This series introduces an --object-id option to git merge-file such that, instead of reading and writing from files on the system, it reads from and writes to the object store using blobs.

Changes from v1:
* Improve error handling
* Re-add `-p` argument for documentation
brian m. carlson (1):
  merge-file: add an option to process object IDs
 Documentation/git-merge-file.txt | 20 +++++++++++
 builtin/merge-file.c             | 62 +++++++++++++++++++++++---------
 t/t6403-merge-file.sh            | 58 ++++++++++++++++++++++++++++++
 3 files changed, 124 insertions(+), 16 deletions(-)
brian m. carlson· Oct 30, 2023, 16:26 UTC · re: brian m. carlson · lore

[PATCH v2 1/1] merge-file: add an option to process object IDs

From: "brian m. carlson" <bk2204@github.com>

git merge-file knows how to merge files on the file system already. It would be helpful, however, to allow it to also merge single blobs. Teach it an `--object-id` option which means that its arguments are object IDs and not files to allow it to do so.

Since we obviously won't be writing the data to the first argument, imply the -p option so we write to standard output.

We handle the empty blob specially since read_mmblob doesn't read it directly and otherwise users cannot specify an empty ancestor.

Signed-off-by: brian m. carlson <bk2204@github.com>
---
 Documentation/git-merge-file.txt | 20 +++++++++++
 builtin/merge-file.c             | 62 +++++++++++++++++++++++---------
 t/t6403-merge-file.sh            | 58 ++++++++++++++++++++++++++++++
 3 files changed, 124 insertions(+), 16 deletions(-)
Show changes to 3 files +124 −16

Documentation/git-merge-file.txt, builtin/merge-file.c, t/t6403-merge-file.sh

diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
index 7e9093fab6..a4de2bd297 100644
--- a/Documentation/git-merge-file.txt
+++ b/Documentation/git-merge-file.txt
@@ -12,6 +12,9 @@ SYNOPSIS
 'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
 	[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
 	[--[no-]diff3] <current-file> <base-file> <other-file>
+'git merge-file' --object-id [-L <current-name> [-L <base-name> [-L <other-name>]]]
+	[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
+	[--[no-]diff3] <current-oid> <base-oid> <other-oid>
 
 
 DESCRIPTION
@@ -40,6 +43,10 @@ however, these conflicts are resolved favouring lines from `<current-file>`,
 lines from `<other-file>`, or lines from both respectively.  The length of the
 conflict markers can be given with the `--marker-size` option.
 
+If `--object-id` is specified, exactly the same behavior occurs, except that
+instead of specifying what to merge as files, it is specified as a list of
+object IDs referring to blobs.
+
 The exit value of this program is negative on error, and the number of
 conflicts otherwise (truncated to 127 if there are more than that many
 conflicts). If the merge was clean, the exit value is 0.
@@ -52,6 +59,14 @@ linkgit:git[1].
 OPTIONS
 -------
 
+--object-id::
+	Specify the contents to merge as blobs in the current repository instead of
+	files.  In this case, the operation must take place within a valid repository.
++
+If the `-p` option is specified, the merged file (including conflicts, if any)
+goes to standard output as normal; otherwise, the merged file is written to the
+object store and the object ID of its blob is written to standard output.
+
 -L <label>::
 	This option may be given up to three times, and
 	specifies labels to be used in place of the
@@ -93,6 +108,11 @@ EXAMPLES
 	merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
 	`a` and `c` instead of `tmp/a123` and `tmp/c345`.
 
+`git merge-file -p --object-id abc1234 def567 890abcd`::
+
+	combines the changes of the blob abc1234 and 890abcd since def567,
+	tries to merge them and writes the result to standard output
+
 GIT
 ---
 Part of the linkgit:git[1] suite
diff --git a/builtin/merge-file.c b/builtin/merge-file.c
index d7eb4c6540..832c93d8d5 100644
--- a/builtin/merge-file.c
+++ b/builtin/merge-file.c
@@ -1,5 +1,8 @@
 #include "builtin.h"
 #include "abspath.h"
+#include "hex.h"
+#include "object-name.h"
+#include "object-store.h"
 #include "config.h"
 #include "gettext.h"
 #include "setup.h"
@@ -31,10 +34,11 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 	mmfile_t mmfs[3] = { 0 };
 	mmbuffer_t result = { 0 };
 	xmparam_t xmp = { 0 };
-	int ret = 0, i = 0, to_stdout = 0;
+	int ret = 0, i = 0, to_stdout = 0, object_id = 0;
 	int quiet = 0;
 	struct option options[] = {
 		OPT_BOOL('p', "stdout", &to_stdout, N_("send results to standard output")),
+		OPT_BOOL(0,   "object-id", &object_id, N_("use object IDs instead of filenames")),
 		OPT_SET_INT(0, "diff3", &xmp.style, N_("use a diff3 based merge"), XDL_MERGE_DIFF3),
 		OPT_SET_INT(0, "zdiff3", &xmp.style, N_("use a zealous diff3 based merge"),
 				XDL_MERGE_ZEALOUS_DIFF3),
@@ -71,8 +75,12 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 			return error_errno("failed to redirect stderr to /dev/null");
 	}
 
+	if (object_id)
+		setup_git_directory();
+
 	for (i = 0; i < 3; i++) {
 		char *fname;
+		struct object_id oid;
 		mmfile_t *mmf = mmfs + i;
 
 		if (!names[i])
@@ -80,12 +88,22 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 
 		fname = prefix_filename(prefix, argv[i]);
 
-		if (read_mmfile(mmf, fname))
+		if (object_id) {
+			if (repo_get_oid(the_repository, argv[i], &oid))
+				ret = error(_("object '%s' does not exist"),
+					      argv[i]);
+			else if (!oideq(&oid, the_hash_algo->empty_blob))
+				read_mmblob(mmf, &oid);
+			else
+				read_mmfile(mmf, "/dev/null");
+		} else if (read_mmfile(mmf, fname)) {
 			ret = -1;
-		else if (mmf->size > MAX_XDIFF_SIZE ||
-			 buffer_is_binary(mmf->ptr, mmf->size))
+		}
+		if (ret != -1 && (mmf->size > MAX_XDIFF_SIZE ||
+		    buffer_is_binary(mmf->ptr, mmf->size))) {
 			ret = error("Cannot merge binary files: %s",
 				    argv[i]);
+		}
 
 		free(fname);
 		if (ret)
@@ -99,20 +117,32 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 	ret = xdl_merge(mmfs + 1, mmfs + 0, mmfs + 2, &xmp, &result);
 
 	if (ret >= 0) {
-		const char *filename = argv[0];
-		char *fpath = prefix_filename(prefix, argv[0]);
-		FILE *f = to_stdout ? stdout : fopen(fpath, "wb");
+		if (object_id && !to_stdout) {
+			struct object_id oid;
+			if (result.size) {
+				if (write_object_file(result.ptr, result.size, OBJ_BLOB, &oid) < 0)
+					ret = error(_("Could not write object file"));
+			} else {
+				oidcpy(&oid, the_hash_algo->empty_blob);
+			}
+			if (ret >= 0)
+				printf("%s\n", oid_to_hex(&oid));
+		} else {
+			const char *filename = argv[0];
+			char *fpath = prefix_filename(prefix, argv[0]);
+			FILE *f = to_stdout ? stdout : fopen(fpath, "wb");
 
-		if (!f)
-			ret = error_errno("Could not open %s for writing",
-					  filename);
-		else if (result.size &&
-			 fwrite(result.ptr, result.size, 1, f) != 1)
-			ret = error_errno("Could not write to %s", filename);
-		else if (fclose(f))
-			ret = error_errno("Could not close %s", filename);
+			if (!f)
+				ret = error_errno("Could not open %s for writing",
+						  filename);
+			else if (result.size &&
+				 fwrite(result.ptr, result.size, 1, f) != 1)
+				ret = error_errno("Could not write to %s", filename);
+			else if (fclose(f))
+				ret = error_errno("Could not close %s", filename);
+			free(fpath);
+		}
 		free(result.ptr);
-		free(fpath);
 	}
 
 	if (ret > 127)
diff --git a/t/t6403-merge-file.sh b/t/t6403-merge-file.sh
index 1a7082323d..2c92209eca 100755
--- a/t/t6403-merge-file.sh
+++ b/t/t6403-merge-file.sh
@@ -65,11 +65,30 @@ test_expect_success 'merge with no changes' '
 	test_cmp test.txt orig.txt
 '
 
+test_expect_success 'merge with no changes with --object-id' '
+	git add orig.txt &&
+	git merge-file -p --object-id :orig.txt :orig.txt :orig.txt >actual &&
+	test_cmp actual orig.txt
+'
+
 test_expect_success "merge without conflict" '
 	cp new1.txt test.txt &&
 	git merge-file test.txt orig.txt new2.txt
 '
 
+test_expect_success 'merge without conflict with --object-id' '
+	git add orig.txt new2.txt &&
+	git merge-file --object-id :orig.txt :orig.txt :new2.txt >actual &&
+	git rev-parse :new2.txt >expected &&
+	test_cmp actual expected
+'
+
+test_expect_success 'can accept object ID with --object-id' '
+	git merge-file --object-id $(test_oid empty_blob) $(test_oid empty_blob) :new2.txt >actual &&
+	git rev-parse :new2.txt >expected &&
+	test_cmp actual expected
+'
+
 test_expect_success 'works in subdirectory' '
 	mkdir dir &&
 	cp new1.txt dir/a.txt &&
@@ -138,6 +157,31 @@ test_expect_success "expected conflict markers" '
 	test_cmp expect.txt test.txt
 '
 
+test_expect_success "merge with conflicts with --object-id" '
+	git add backup.txt orig.txt new3.txt &&
+	test_must_fail git merge-file -p --object-id :backup.txt :orig.txt :new3.txt >actual &&
+	sed -e "s/<< test.txt/<< :backup.txt/" \
+	    -e "s/>> new3.txt/>> :new3.txt/" \
+	    expect.txt >expect &&
+	test_cmp expect actual &&
+	test_must_fail git merge-file --object-id :backup.txt :orig.txt :new3.txt >oid &&
+	git cat-file blob "$(cat oid)" >actual &&
+	test_cmp expect actual
+'
+
+test_expect_success "merge with conflicts with --object-id with labels" '
+	git add backup.txt orig.txt new3.txt &&
+	test_must_fail git merge-file -p --object-id \
+		-L test.txt -L orig.txt -L new3.txt \
+		:backup.txt :orig.txt :new3.txt >actual &&
+	test_cmp expect.txt actual &&
+	test_must_fail git merge-file --object-id \
+		-L test.txt -L orig.txt -L new3.txt \
+		:backup.txt :orig.txt :new3.txt >oid &&
+	git cat-file blob "$(cat oid)" >actual &&
+	test_cmp expect.txt actual
+'
+
 test_expect_success "merge conflicting with --ours" '
 	cp backup.txt test.txt &&
 
@@ -256,6 +300,14 @@ test_expect_success 'binary files cannot be merged' '
 	grep "Cannot merge binary files" merge.err
 '
 
+test_expect_success 'binary files cannot be merged with --object-id' '
+	cp "$TEST_DIRECTORY"/test-binary-1.png . &&
+	git add orig.txt new1.txt test-binary-1.png &&
+	test_must_fail git merge-file --object-id \
+		:orig.txt :test-binary-1.png :new1.txt 2> merge.err &&
+	grep "Cannot merge binary files" merge.err
+'
+
 test_expect_success 'MERGE_ZEALOUS simplifies non-conflicts' '
 	sed -e "s/deerit.\$/deerit;/" -e "s/me;\$/me./" <new5.txt >new6.txt &&
 	sed -e "s/deerit.\$/deerit,/" -e "s/me;\$/me,/" <new5.txt >new7.txt &&
@@ -389,4 +441,10 @@ test_expect_success 'conflict sections match existing line endings' '
 	test $(tr "\015" Q <nolf.txt | grep "^[<=>].*Q$" | wc -l) = 0
 '
 
+test_expect_success '--object-id fails without repository' '
+	empty="$(test_oid empty_blob)" &&
+	nongit test_must_fail git merge-file --object-id $empty $empty $empty 2>err &&
+	grep "not a git repository" err
+'
+
 test_done
Martin Ågren· Oct 31, 2023, 21:48 UTC · re: brian m. carlson · lore

Re: [PATCH v2 1/1] merge-file: add an option to process object IDs

On Mon, 30 Oct 2023 at 17:37, brian m. carlson <sandals@crustytoothpaste.net> wrote:
>
> Since we obviously won't be writing the data to the first argument,
> imply the -p option so we write to standard output.

This paragraph changed from v1, but this doesn't match the actual behavior, from what I can tell: `-p` is not implied.

Show 6 quoted lines
>  'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
>         [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
>         [--[no-]diff3] <current-file> <base-file> <other-file>
> +'git merge-file' --object-id [-L <current-name> [-L <base-name> [-L <other-name>]]]
> +       [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
> +       [--[no-]diff3] <current-oid> <base-oid> <other-oid>

I see this duplicated synopsis was discussed on v1, and that the difference here is "file" vs "oid". It seems we could avoid this redundancy and risk of going out of sync with no downside that I can see by instead dropping all these "-file". See below for a patch that could go in as a preparatory step.

> +If `--object-id` is specified, exactly the same behavior occurs, except that
> +instead of specifying what to merge as files, it is specified as a list of
> +object IDs referring to blobs.
Makes sense.
> +If the `-p` option is specified, the merged file (including conflicts, if any)
> +goes to standard output as normal; otherwise, the merged file is written to the
> +object store and the object ID of its blob is written to standard output.
(Here, `-p` is not implied.)
Show 6 quoted lines
> +test_expect_success 'merge without conflict with --object-id' '
> +       git add orig.txt new2.txt &&
> +       git merge-file --object-id :orig.txt :orig.txt :new2.txt >actual &&
> +       git rev-parse :new2.txt >expected &&
> +       test_cmp actual expected
> +'
(Here, `-p` is not implied.)
Martin
-- >8 --
Subject: [PATCH] git-merge-file doc: drop "-file" from argument placeholders

`git merge-file` takes three positional arguments. Each of them is documented as `<foo-file>`. In preparation for teaching this command to alternatively take three object IDs, make these placeholders a bit more generic by dropping the "-file" parts. Instead, clarify early that the three arguments are filenames. Even after the next commit, we can afford to present this file-centric view up front and in the general discussion, since it will remain the default one.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
 Documentation/git-merge-file.txt | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)
Show changes to Documentation/git-merge-file.txt +11 −10
diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
index 7e9093fab6..bf0a18cf02 100644
--- a/Documentation/git-merge-file.txt
+++ b/Documentation/git-merge-file.txt
@@ -11,19 +11,20 @@ SYNOPSIS
 [verse]
 'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
 	[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
-	[--[no-]diff3] <current-file> <base-file> <other-file>
+	[--[no-]diff3] <current> <base> <other>
 
 
 DESCRIPTION
 -----------
-'git merge-file' incorporates all changes that lead from the `<base-file>`
-to `<other-file>` into `<current-file>`. The result ordinarily goes into
-`<current-file>`. 'git merge-file' is useful for combining separate changes
-to an original. Suppose `<base-file>` is the original, and both
-`<current-file>` and `<other-file>` are modifications of `<base-file>`,
+Given three files `<current>`, `<base>` and `<other>`,
+'git merge-file' incorporates all changes that lead from `<base>`
+to `<other>` into `<current>`. The result ordinarily goes into
+`<current>`. 'git merge-file' is useful for combining separate changes
+to an original. Suppose `<base>` is the original, and both
+`<current>` and `<other>` are modifications of `<base>`,
 then 'git merge-file' combines both changes.
 
-A conflict occurs if both `<current-file>` and `<other-file>` have changes
+A conflict occurs if both `<current>` and `<other>` have changes
 in a common segment of lines. If a conflict is found, 'git merge-file'
 normally outputs a warning and brackets the conflict with lines containing
 <<<<<<< and >>>>>>> markers. A typical conflict will look like this:
@@ -36,8 +37,8 @@ normally outputs a warning and brackets the conflict with lines containing
 
 If there are conflicts, the user should edit the result and delete one of
 the alternatives.  When `--ours`, `--theirs`, or `--union` option is in effect,
-however, these conflicts are resolved favouring lines from `<current-file>`,
-lines from `<other-file>`, or lines from both respectively.  The length of the
+however, these conflicts are resolved favouring lines from `<current>`,
+lines from `<other>`, or lines from both respectively.  The length of the
 conflict markers can be given with the `--marker-size` option.
 
 The exit value of this program is negative on error, and the number of
@@ -62,7 +63,7 @@ OPTIONS
 
 -p::
 	Send results to standard output instead of overwriting
-	`<current-file>`.
+	`<current>`.
 
 -q::
 	Quiet; do not warn about conflicts.
-- 
2.42.0.899.gfd14d11e2b
brian m. carlson· Oct 31, 2023, 22:31 UTC · re: Martin Ågren · lore

Re: [PATCH v2 1/1] merge-file: add an option to process object IDs

On 2023-10-31 at 21:48:57, Martin Ågren wrote:
Show 8 quoted lines
> 
> On Mon, 30 Oct 2023 at 17:37, brian m. carlson <sandals@crustytoothpaste.net> wrote:
> >
> > Since we obviously won't be writing the data to the first argument,
> > imply the -p option so we write to standard output.
> 
> This paragraph changed from v1, but this doesn't match the actual
> behavior, from what I can tell: `-p` is not implied.

Yes, apparently that commit message snuck back in after it having been edited out.

Show 10 quoted lines
> -- >8 --
> Subject: [PATCH] git-merge-file doc: drop "-file" from argument placeholders
> 
> `git merge-file` takes three positional arguments. Each of them is
> documented as `<foo-file>`. In preparation for teaching this command to
> alternatively take three object IDs, make these placeholders a bit more
> generic by dropping the "-file" parts. Instead, clarify early that the
> three arguments are filenames. Even after the next commit, we can afford
> to present this file-centric view up front and in the general
> discussion, since it will remain the default one.

This seems reasonable. Junio, do you want to sneak this in and fix the commit message above, or do you want me to do a v3?

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Junio C Hamano· Nov 1, 2023, 03:44 UTC · re: brian m. carlson · lore

Re: [PATCH v2 1/1] merge-file: add an option to process object IDs

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> This seems reasonable.  Junio, do you want to sneak this in and fix the
> commit message above, or do you want me to do a v3?

As it hasn't hit 'next' on my end, I'd prefer to see a version I can blindly apply without having to care all the details of what was discussed. Thanks.

brian m. carlson· Nov 1, 2023, 19:16 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 1/1] merge-file: add an option to process object IDs

On 2023-11-01 at 03:44:30, Junio C Hamano wrote:
Show 8 quoted lines
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > This seems reasonable.  Junio, do you want to sneak this in and fix the
> > commit message above, or do you want me to do a v3?
> 
> As it hasn't hit 'next' on my end, I'd prefer to see a version I can
> blindly apply without having to care all the details of what was
> discussed.  Thanks.
I'll send out a v3 shortly.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Elijah Newren· Oct 30, 2023, 17:15 UTC · re: brian m. carlson · lore

Re: [PATCH v2 0/1] Object ID support for git merge-file

On Mon, Oct 30, 2023 at 9:27 AM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 16 quoted lines
>
> This series introduces an --object-id option to git merge-file such
> that, instead of reading and writing from files on the system, it reads
> from and writes to the object store using blobs.
>
> Changes from v1:
> * Improve error handling
> * Re-add `-p` argument for documentation
>
> brian m. carlson (1):
>   merge-file: add an option to process object IDs
>
>  Documentation/git-merge-file.txt | 20 +++++++++++
>  builtin/merge-file.c             | 62 +++++++++++++++++++++++---------
>  t/t6403-merge-file.sh            | 58 ++++++++++++++++++++++++++++++
>  3 files changed, 124 insertions(+), 16 deletions(-)
Thanks, this version looks good to me.
Junio C Hamano· Oct 31, 2023, 00:03 UTC · re: Elijah Newren · lore

Re: [PATCH v2 0/1] Object ID support for git merge-file

Elijah Newren <newren@gmail.com> writes:
Show 20 quoted lines
> On Mon, Oct 30, 2023 at 9:27 AM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>>
>> This series introduces an --object-id option to git merge-file such
>> that, instead of reading and writing from files on the system, it reads
>> from and writes to the object store using blobs.
>>
>> Changes from v1:
>> * Improve error handling
>> * Re-add `-p` argument for documentation
>>
>> brian m. carlson (1):
>>   merge-file: add an option to process object IDs
>>
>>  Documentation/git-merge-file.txt | 20 +++++++++++
>>  builtin/merge-file.c             | 62 +++++++++++++++++++++++---------
>>  t/t6403-merge-file.sh            | 58 ++++++++++++++++++++++++++++++
>>  3 files changed, 124 insertions(+), 16 deletions(-)
>
> Thanks, this version looks good to me.
Thanks, both.  Will queue.
Phillip Wood· Oct 31, 2023, 11:05 UTC · re: brian m. carlson · lore

Re: [PATCH v2 0/1] Object ID support for git merge-file

Hi brian
Thanks for the re-roll, this version looks good to me
Phillip
On 30/10/2023 16:26, brian m. carlson wrote:
Show 17 quoted lines
> This series introduces an --object-id option to git merge-file such
> that, instead of reading and writing from files on the system, it reads
> from and writes to the object store using blobs.
> 
> Changes from v1:
> * Improve error handling
> * Re-add `-p` argument for documentation
> 
> brian m. carlson (1):
>    merge-file: add an option to process object IDs
> 
>   Documentation/git-merge-file.txt | 20 +++++++++++
>   builtin/merge-file.c             | 62 +++++++++++++++++++++++---------
>   t/t6403-merge-file.sh            | 58 ++++++++++++++++++++++++++++++
>   3 files changed, 124 insertions(+), 16 deletions(-)
> 
> 
Junio C Hamano· Oct 31, 2023, 23:06 UTC · re: Phillip Wood · lore

Re: [PATCH v2 0/1] Object ID support for git merge-file

Phillip Wood <phillip.wood123@gmail.com> writes:
Show 5 quoted lines
> Hi brian
>
> Thanks for the re-roll, this version looks good to me
>
> Phillip
Yup, competently done.

I briefly thought about suggesting --blob-id instead of --object-id simply because you'd never want to feed it trees and commits, but the error message from read_mmblob() the users would get mentions 'blob' to signal that non-blob objects are unwelcome, so the name of the optionwould be OK as-is.

Queued.  Let's mark it for 'next'.  Thanks.
brian m. carlson· Nov 1, 2023, 19:24 UTC · re: brian m. carlson · lore

[PATCH v3 0/2] Object ID support for git merge-file

This series introduces an --object-id option to git merge-file such that, instead of reading and writing from files on the system, it reads from and writes to the object store using blobs.

Changes from v2:
* Include a patch from Martin to pre-improve the documentation
* Remove incorrect portion of commit message
Changes from v1:
* Improve error handling
* Re-add `-p` argument for documentation
Martin Ågren (1):
  git-merge-file doc: drop "-file" from argument placeholders
brian m. carlson (1):
  merge-file: add an option to process object IDs
 Documentation/git-merge-file.txt | 38 ++++++++++++++------
 builtin/merge-file.c             | 62 +++++++++++++++++++++++---------
 t/t6403-merge-file.sh            | 58 ++++++++++++++++++++++++++++++
 3 files changed, 132 insertions(+), 26 deletions(-)
Range-diff against v2:
-:  ---------- > 1:  21a96acf42 git-merge-file doc: drop "-file" from argument placeholders
1:  9cd4220a3b ! 2:  b1978a7b5c merge-file: add an option to process object IDs
    @@ Commit message
         Teach it an `--object-id` option which means that its arguments are
         object IDs and not files to allow it to do so.
     
    -    Since we obviously won't be writing the data to the first argument,
    -    imply the -p option so we write to standard output.
    -
         We handle the empty blob specially since read_mmblob doesn't read it
         directly and otherwise users cannot specify an empty ancestor.
     
    @@ Commit message
     
      ## Documentation/git-merge-file.txt ##
     @@ Documentation/git-merge-file.txt: SYNOPSIS
    + [verse]
      'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
      	[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
    - 	[--[no-]diff3] <current-file> <base-file> <other-file>
    -+'git merge-file' --object-id [-L <current-name> [-L <base-name> [-L <other-name>]]]
    -+	[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
    -+	[--[no-]diff3] <current-oid> <base-oid> <other-oid>
    +-	[--[no-]diff3] <current> <base> <other>
    ++	[--[no-]diff3] [--object-id] <current> <base> <other>
      
      
      DESCRIPTION
    -@@ Documentation/git-merge-file.txt: however, these conflicts are resolved favouring lines from `<current-file>`,
    - lines from `<other-file>`, or lines from both respectively.  The length of the
    +@@ Documentation/git-merge-file.txt: however, these conflicts are resolved favouring lines from `<current>`,
    + lines from `<other>`, or lines from both respectively.  The length of the
      conflict markers can be given with the `--marker-size` option.
      
     +If `--object-id` is specified, exactly the same behavior occurs, except that
brian m. carlson· Nov 1, 2023, 19:24 UTC · re: brian m. carlson · lore

[PATCH v3 1/2] git-merge-file doc: drop "-file" from argument placeholders

From: Martin Ågren <martin.agren@gmail.com>

`git merge-file` takes three positional arguments. Each of them is documented as `<foo-file>`. In preparation for teaching this command to alternatively take three object IDs, make these placeholders a bit more generic by dropping the "-file" parts. Instead, clarify early that the three arguments are filenames. Even after the next commit, we can afford to present this file-centric view up front and in the general discussion, since it will remain the default one.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: brian m. carlson <bk2204@github.com>
---
 Documentation/git-merge-file.txt | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)
Show changes to Documentation/git-merge-file.txt +11 −10
diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
index 7e9093fab6..bf0a18cf02 100644
--- a/Documentation/git-merge-file.txt
+++ b/Documentation/git-merge-file.txt
@@ -11,19 +11,20 @@ SYNOPSIS
 [verse]
 'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
 	[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
-	[--[no-]diff3] <current-file> <base-file> <other-file>
+	[--[no-]diff3] <current> <base> <other>
 
 
 DESCRIPTION
 -----------
-'git merge-file' incorporates all changes that lead from the `<base-file>`
-to `<other-file>` into `<current-file>`. The result ordinarily goes into
-`<current-file>`. 'git merge-file' is useful for combining separate changes
-to an original. Suppose `<base-file>` is the original, and both
-`<current-file>` and `<other-file>` are modifications of `<base-file>`,
+Given three files `<current>`, `<base>` and `<other>`,
+'git merge-file' incorporates all changes that lead from `<base>`
+to `<other>` into `<current>`. The result ordinarily goes into
+`<current>`. 'git merge-file' is useful for combining separate changes
+to an original. Suppose `<base>` is the original, and both
+`<current>` and `<other>` are modifications of `<base>`,
 then 'git merge-file' combines both changes.
 
-A conflict occurs if both `<current-file>` and `<other-file>` have changes
+A conflict occurs if both `<current>` and `<other>` have changes
 in a common segment of lines. If a conflict is found, 'git merge-file'
 normally outputs a warning and brackets the conflict with lines containing
 <<<<<<< and >>>>>>> markers. A typical conflict will look like this:
@@ -36,8 +37,8 @@ normally outputs a warning and brackets the conflict with lines containing
 
 If there are conflicts, the user should edit the result and delete one of
 the alternatives.  When `--ours`, `--theirs`, or `--union` option is in effect,
-however, these conflicts are resolved favouring lines from `<current-file>`,
-lines from `<other-file>`, or lines from both respectively.  The length of the
+however, these conflicts are resolved favouring lines from `<current>`,
+lines from `<other>`, or lines from both respectively.  The length of the
 conflict markers can be given with the `--marker-size` option.
 
 The exit value of this program is negative on error, and the number of
@@ -62,7 +63,7 @@ OPTIONS
 
 -p::
 	Send results to standard output instead of overwriting
-	`<current-file>`.
+	`<current>`.
 
 -q::
 	Quiet; do not warn about conflicts.
Junio C Hamano· Nov 1, 2023, 23:53 UTC · re: brian m. carlson · lore

Re: [PATCH v3 1/2] git-merge-file doc: drop "-file" from argument placeholders

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 5 quoted lines
> From: Martin Ågren <martin.agren@gmail.com>
>
> `git merge-file` takes three positional arguments. Each of them is
> documented as `<foo-file>`. In preparation for teaching this command to
> alternatively take three object IDs, make these placeholders a bit more

Minor nit. Don't we want to say "three blob object names"? Unless we plan to grow this feature into accepting three tree object names, that is.

Martin Ågren· Nov 2, 2023, 08:53 UTC · re: Junio C Hamano · lore

Re: [PATCH v3 1/2] git-merge-file doc: drop "-file" from argument placeholders

On Thu, 2 Nov 2023 at 00:53, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
>
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > From: Martin Ågren <martin.agren@gmail.com>
> >
> > `git merge-file` takes three positional arguments. Each of them is
> > documented as `<foo-file>`. In preparation for teaching this command to
> > alternatively take three object IDs, make these placeholders a bit more
>
> Minor nit.  Don't we want to say "three blob object names"?  Unless
> we plan to grow this feature into accepting three tree object names,
> that is.

Hmm, yeah. Or just "three non-filename arguments". I do wonder: doesn't this mean that the second patch could/should possibly move away from the notion of "object ID"/`--object-id`? (That's not trying to shift any blame from one patch to the other, that's my honest reaction.)

Ah, yes, I thought I recognized this. Quoting your response [1] to v2:
Show 5 quoted lines
> I briefly thought about suggesting --blob-id instead of --object-id
> simply because you'd never want to feed it trees and commits, but
> the error message from read_mmblob() the users would get mentions
> 'blob' to signal that non-blob objects are unwelcome, so the name of
> the optionwould be OK as-is.

Maybe you having a similar reaction a second time makes this smell a bit more?

[1] https://lore.kernel.org/git/xmqqo7ge2xzl.fsf@gitster.g/
Martin
brian m. carlson· Nov 2, 2023, 09:18 UTC · re: Martin Ågren · lore

Re: [PATCH v3 1/2] git-merge-file doc: drop "-file" from argument placeholders

On 2023-11-02 at 08:53:36, Martin Ågren wrote:
Show 18 quoted lines
> On Thu, 2 Nov 2023 at 00:53, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> >
> > > From: Martin Ågren <martin.agren@gmail.com>
> > >
> > > `git merge-file` takes three positional arguments. Each of them is
> > > documented as `<foo-file>`. In preparation for teaching this command to
> > > alternatively take three object IDs, make these placeholders a bit more
> >
> > Minor nit.  Don't we want to say "three blob object names"?  Unless
> > we plan to grow this feature into accepting three tree object names,
> > that is.
> 
> Hmm, yeah. Or just "three non-filename arguments". I do wonder: doesn't
> this mean that the second patch could/should possibly move away from the
> notion of "object ID"/`--object-id`? (That's not trying to shift any
> blame from one patch to the other, that's my honest reaction.)

Not specifying an option would make this ambiguous. What if I have a file named "e69de29bb2d1d6434b8b29ae775ad8c2e48c5391"? Is that the empty blob, or is it that file? Normally we have ways to disambiguate this, but those don't work here because of the positional arguments.

Show 10 quoted lines
> Ah, yes, I thought I recognized this. Quoting your response [1] to v2:
> 
> > I briefly thought about suggesting --blob-id instead of --object-id
> > simply because you'd never want to feed it trees and commits, but
> > the error message from read_mmblob() the users would get mentions
> > 'blob' to signal that non-blob objects are unwelcome, so the name of
> > the optionwould be OK as-is.
> 
> Maybe you having a similar reaction a second time makes this smell a bit
> more?

I think the name is fine. We don't typically use the phrase "blob ID" anywhere, but we do say "object ID". We'd need to say "--blob", but I'm not sure that's an improvement, and I fear it may be less understandable.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Martin Ågren· Nov 2, 2023, 09:29 UTC · re: brian m. carlson · lore

Re: [PATCH v3 1/2] git-merge-file doc: drop "-file" from argument placeholders

On Thu, 2 Nov 2023 at 10:18, brian m. carlson <sandals@crustytoothpaste.net> wrote:

>
> On 2023-11-02 at 08:53:36, Martin Ågren wrote:
Show 9 quoted lines
> > Hmm, yeah. Or just "three non-filename arguments". I do wonder: doesn't
> > this mean that the second patch could/should possibly move away from the
> > notion of "object ID"/`--object-id`? (That's not trying to shift any
> > blame from one patch to the other, that's my honest reaction.)
>
> Not specifying an option would make this ambiguous.  What if I have a
> file named "e69de29bb2d1d6434b8b29ae775ad8c2e48c5391"?  Is that the
> empty blob, or is it that file?  Normally we have ways to disambiguate
> this, but those don't work here because of the positional arguments.

I didn't intend to suggest dropping the new option altogether, sorry for being unclear. I meant moving from `--object-id` to something else, such as `--blob` that you mention. Completely agreed that something explicit is needed here and that heuristics aren't possible.

> I think the name is fine.  We don't typically use the phrase "blob ID"
> anywhere, but we do say "object ID".  We'd need to say "--blob", but
> I'm not sure that's an improvement, and I fear it may be less
> understandable.
Agreed. Thanks.
Martin
Junio C Hamano· Nov 2, 2023, 16:28 UTC · re: Martin Ågren · lore

Re: [PATCH v3 1/2] git-merge-file doc: drop "-file" from argument placeholders

Martin Ågren <martin.agren@gmail.com> writes:
> Maybe you having a similar reaction a second time makes this smell a bit
> more?

Not at all. I am perfectly OK with --object-*, not --blob-*, as the end-user facing option name. I however strongly prefer to see our log messages record the thought behind the design accurately in order to help future developers when they wonder what our intention was back when the commit was created.

In this case, I want to see that we tell our future selves "even though we named the option 'object', we plan to support blobs and nothing else, at least for now".

Thanks.
brian m. carlson· Nov 1, 2023, 19:24 UTC · re: brian m. carlson · lore

[PATCH v3 2/2] merge-file: add an option to process object IDs

From: "brian m. carlson" <bk2204@github.com>

git merge-file knows how to merge files on the file system already. It would be helpful, however, to allow it to also merge single blobs. Teach it an `--object-id` option which means that its arguments are object IDs and not files to allow it to do so.

We handle the empty blob specially since read_mmblob doesn't read it directly and otherwise users cannot specify an empty ancestor.

Signed-off-by: brian m. carlson <bk2204@github.com>
---
 Documentation/git-merge-file.txt | 19 +++++++++-
 builtin/merge-file.c             | 62 +++++++++++++++++++++++---------
 t/t6403-merge-file.sh            | 58 ++++++++++++++++++++++++++++++
 3 files changed, 122 insertions(+), 17 deletions(-)
Show changes to 3 files +122 −17

Documentation/git-merge-file.txt, builtin/merge-file.c, t/t6403-merge-file.sh

diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
index bf0a18cf02..6a081eacb7 100644
--- a/Documentation/git-merge-file.txt
+++ b/Documentation/git-merge-file.txt
@@ -11,7 +11,7 @@ SYNOPSIS
 [verse]
 'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
 	[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
-	[--[no-]diff3] <current> <base> <other>
+	[--[no-]diff3] [--object-id] <current> <base> <other>
 
 
 DESCRIPTION
@@ -41,6 +41,10 @@ however, these conflicts are resolved favouring lines from `<current>`,
 lines from `<other>`, or lines from both respectively.  The length of the
 conflict markers can be given with the `--marker-size` option.
 
+If `--object-id` is specified, exactly the same behavior occurs, except that
+instead of specifying what to merge as files, it is specified as a list of
+object IDs referring to blobs.
+
 The exit value of this program is negative on error, and the number of
 conflicts otherwise (truncated to 127 if there are more than that many
 conflicts). If the merge was clean, the exit value is 0.
@@ -53,6 +57,14 @@ linkgit:git[1].
 OPTIONS
 -------
 
+--object-id::
+	Specify the contents to merge as blobs in the current repository instead of
+	files.  In this case, the operation must take place within a valid repository.
++
+If the `-p` option is specified, the merged file (including conflicts, if any)
+goes to standard output as normal; otherwise, the merged file is written to the
+object store and the object ID of its blob is written to standard output.
+
 -L <label>::
 	This option may be given up to three times, and
 	specifies labels to be used in place of the
@@ -94,6 +106,11 @@ EXAMPLES
 	merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
 	`a` and `c` instead of `tmp/a123` and `tmp/c345`.
 
+`git merge-file -p --object-id abc1234 def567 890abcd`::
+
+	combines the changes of the blob abc1234 and 890abcd since def567,
+	tries to merge them and writes the result to standard output
+
 GIT
 ---
 Part of the linkgit:git[1] suite
diff --git a/builtin/merge-file.c b/builtin/merge-file.c
index d7eb4c6540..832c93d8d5 100644
--- a/builtin/merge-file.c
+++ b/builtin/merge-file.c
@@ -1,5 +1,8 @@
 #include "builtin.h"
 #include "abspath.h"
+#include "hex.h"
+#include "object-name.h"
+#include "object-store.h"
 #include "config.h"
 #include "gettext.h"
 #include "setup.h"
@@ -31,10 +34,11 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 	mmfile_t mmfs[3] = { 0 };
 	mmbuffer_t result = { 0 };
 	xmparam_t xmp = { 0 };
-	int ret = 0, i = 0, to_stdout = 0;
+	int ret = 0, i = 0, to_stdout = 0, object_id = 0;
 	int quiet = 0;
 	struct option options[] = {
 		OPT_BOOL('p', "stdout", &to_stdout, N_("send results to standard output")),
+		OPT_BOOL(0,   "object-id", &object_id, N_("use object IDs instead of filenames")),
 		OPT_SET_INT(0, "diff3", &xmp.style, N_("use a diff3 based merge"), XDL_MERGE_DIFF3),
 		OPT_SET_INT(0, "zdiff3", &xmp.style, N_("use a zealous diff3 based merge"),
 				XDL_MERGE_ZEALOUS_DIFF3),
@@ -71,8 +75,12 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 			return error_errno("failed to redirect stderr to /dev/null");
 	}
 
+	if (object_id)
+		setup_git_directory();
+
 	for (i = 0; i < 3; i++) {
 		char *fname;
+		struct object_id oid;
 		mmfile_t *mmf = mmfs + i;
 
 		if (!names[i])
@@ -80,12 +88,22 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 
 		fname = prefix_filename(prefix, argv[i]);
 
-		if (read_mmfile(mmf, fname))
+		if (object_id) {
+			if (repo_get_oid(the_repository, argv[i], &oid))
+				ret = error(_("object '%s' does not exist"),
+					      argv[i]);
+			else if (!oideq(&oid, the_hash_algo->empty_blob))
+				read_mmblob(mmf, &oid);
+			else
+				read_mmfile(mmf, "/dev/null");
+		} else if (read_mmfile(mmf, fname)) {
 			ret = -1;
-		else if (mmf->size > MAX_XDIFF_SIZE ||
-			 buffer_is_binary(mmf->ptr, mmf->size))
+		}
+		if (ret != -1 && (mmf->size > MAX_XDIFF_SIZE ||
+		    buffer_is_binary(mmf->ptr, mmf->size))) {
 			ret = error("Cannot merge binary files: %s",
 				    argv[i]);
+		}
 
 		free(fname);
 		if (ret)
@@ -99,20 +117,32 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
 	ret = xdl_merge(mmfs + 1, mmfs + 0, mmfs + 2, &xmp, &result);
 
 	if (ret >= 0) {
-		const char *filename = argv[0];
-		char *fpath = prefix_filename(prefix, argv[0]);
-		FILE *f = to_stdout ? stdout : fopen(fpath, "wb");
+		if (object_id && !to_stdout) {
+			struct object_id oid;
+			if (result.size) {
+				if (write_object_file(result.ptr, result.size, OBJ_BLOB, &oid) < 0)
+					ret = error(_("Could not write object file"));
+			} else {
+				oidcpy(&oid, the_hash_algo->empty_blob);
+			}
+			if (ret >= 0)
+				printf("%s\n", oid_to_hex(&oid));
+		} else {
+			const char *filename = argv[0];
+			char *fpath = prefix_filename(prefix, argv[0]);
+			FILE *f = to_stdout ? stdout : fopen(fpath, "wb");
 
-		if (!f)
-			ret = error_errno("Could not open %s for writing",
-					  filename);
-		else if (result.size &&
-			 fwrite(result.ptr, result.size, 1, f) != 1)
-			ret = error_errno("Could not write to %s", filename);
-		else if (fclose(f))
-			ret = error_errno("Could not close %s", filename);
+			if (!f)
+				ret = error_errno("Could not open %s for writing",
+						  filename);
+			else if (result.size &&
+				 fwrite(result.ptr, result.size, 1, f) != 1)
+				ret = error_errno("Could not write to %s", filename);
+			else if (fclose(f))
+				ret = error_errno("Could not close %s", filename);
+			free(fpath);
+		}
 		free(result.ptr);
-		free(fpath);
 	}
 
 	if (ret > 127)
diff --git a/t/t6403-merge-file.sh b/t/t6403-merge-file.sh
index 1a7082323d..2c92209eca 100755
--- a/t/t6403-merge-file.sh
+++ b/t/t6403-merge-file.sh
@@ -65,11 +65,30 @@ test_expect_success 'merge with no changes' '
 	test_cmp test.txt orig.txt
 '
 
+test_expect_success 'merge with no changes with --object-id' '
+	git add orig.txt &&
+	git merge-file -p --object-id :orig.txt :orig.txt :orig.txt >actual &&
+	test_cmp actual orig.txt
+'
+
 test_expect_success "merge without conflict" '
 	cp new1.txt test.txt &&
 	git merge-file test.txt orig.txt new2.txt
 '
 
+test_expect_success 'merge without conflict with --object-id' '
+	git add orig.txt new2.txt &&
+	git merge-file --object-id :orig.txt :orig.txt :new2.txt >actual &&
+	git rev-parse :new2.txt >expected &&
+	test_cmp actual expected
+'
+
+test_expect_success 'can accept object ID with --object-id' '
+	git merge-file --object-id $(test_oid empty_blob) $(test_oid empty_blob) :new2.txt >actual &&
+	git rev-parse :new2.txt >expected &&
+	test_cmp actual expected
+'
+
 test_expect_success 'works in subdirectory' '
 	mkdir dir &&
 	cp new1.txt dir/a.txt &&
@@ -138,6 +157,31 @@ test_expect_success "expected conflict markers" '
 	test_cmp expect.txt test.txt
 '
 
+test_expect_success "merge with conflicts with --object-id" '
+	git add backup.txt orig.txt new3.txt &&
+	test_must_fail git merge-file -p --object-id :backup.txt :orig.txt :new3.txt >actual &&
+	sed -e "s/<< test.txt/<< :backup.txt/" \
+	    -e "s/>> new3.txt/>> :new3.txt/" \
+	    expect.txt >expect &&
+	test_cmp expect actual &&
+	test_must_fail git merge-file --object-id :backup.txt :orig.txt :new3.txt >oid &&
+	git cat-file blob "$(cat oid)" >actual &&
+	test_cmp expect actual
+'
+
+test_expect_success "merge with conflicts with --object-id with labels" '
+	git add backup.txt orig.txt new3.txt &&
+	test_must_fail git merge-file -p --object-id \
+		-L test.txt -L orig.txt -L new3.txt \
+		:backup.txt :orig.txt :new3.txt >actual &&
+	test_cmp expect.txt actual &&
+	test_must_fail git merge-file --object-id \
+		-L test.txt -L orig.txt -L new3.txt \
+		:backup.txt :orig.txt :new3.txt >oid &&
+	git cat-file blob "$(cat oid)" >actual &&
+	test_cmp expect.txt actual
+'
+
 test_expect_success "merge conflicting with --ours" '
 	cp backup.txt test.txt &&
 
@@ -256,6 +300,14 @@ test_expect_success 'binary files cannot be merged' '
 	grep "Cannot merge binary files" merge.err
 '
 
+test_expect_success 'binary files cannot be merged with --object-id' '
+	cp "$TEST_DIRECTORY"/test-binary-1.png . &&
+	git add orig.txt new1.txt test-binary-1.png &&
+	test_must_fail git merge-file --object-id \
+		:orig.txt :test-binary-1.png :new1.txt 2> merge.err &&
+	grep "Cannot merge binary files" merge.err
+'
+
 test_expect_success 'MERGE_ZEALOUS simplifies non-conflicts' '
 	sed -e "s/deerit.\$/deerit;/" -e "s/me;\$/me./" <new5.txt >new6.txt &&
 	sed -e "s/deerit.\$/deerit,/" -e "s/me;\$/me,/" <new5.txt >new7.txt &&
@@ -389,4 +441,10 @@ test_expect_success 'conflict sections match existing line endings' '
 	test $(tr "\015" Q <nolf.txt | grep "^[<=>].*Q$" | wc -l) = 0
 '
 
+test_expect_success '--object-id fails without repository' '
+	empty="$(test_oid empty_blob)" &&
+	nongit test_must_fail git merge-file --object-id $empty $empty $empty 2>err &&
+	grep "not a git repository" err
+'
+
 test_done
Martin Ågren· Nov 2, 2023, 08:51 UTC · re: brian m. carlson · lore

Re: [PATCH v3 2/2] merge-file: add an option to process object IDs

On Wed, 1 Nov 2023 at 20:24, brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 12 quoted lines
>
> From: "brian m. carlson" <bk2204@github.com>
>
> git merge-file knows how to merge files on the file system already.  It
> would be helpful, however, to allow it to also merge single blobs.
> Teach it an `--object-id` option which means that its arguments are
> object IDs and not files to allow it to do so.
>
> We handle the empty blob specially since read_mmblob doesn't read it
> directly and otherwise users cannot specify an empty ancestor.
>
> Signed-off-by: brian m. carlson <bk2204@github.com>
Ok, good solution to the misleading paragraph I noticed: dropping it.
>  'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
>         [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
> -       [--[no-]diff3] <current> <base> <other>
> +       [--[no-]diff3] [--object-id] <current> <base> <other>

Ok. This is where rebasing onto the new, initial patch could possibly have tripped up. Of course you didn't. Looks good.

Martin
Junio C Hamano· Nov 1, 2023, 23:55 UTC · re: brian m. carlson · lore

Re: [PATCH v3 0/2] Object ID support for git merge-file

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 7 quoted lines
> This series introduces an --object-id option to git merge-file such
> that, instead of reading and writing from files on the system, it reads
> from and writes to the object store using blobs.
>
> Changes from v2:
> * Include a patch from Martin to pre-improve the documentation
> * Remove incorrect portion of commit message

Looking good. Will replace. Shall we mark the topic ready for 'next'?

Thanks.

← back to recent threads