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

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

[brian m. carlson]

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

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

[brian m. carlson]

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

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

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

[Eric Sunshine]

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()?

> +               } 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.

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]

On 2023-10-24 at 20:12:52, Eric Sunshine wrote:
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[Elijah Newren]

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.

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

[...]
> @@ -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.)

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

[Elijah Newren]

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.

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

[Phillip Wood]

Hi brian

I agree with everything Elijah said, I just have one more comment

>> @@ -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

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

[Phillip Wood]

On 29/10/2023 06:24, Elijah Newren wrote:
> 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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

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.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[Taylor Blau]

On Sat, Oct 28, 2023 at 11:24:06PM -0700, Elijah Newren wrote:
> 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.

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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

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.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[brian m. carlson]

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

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

[brian m. carlson]

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

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

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

[Elijah Newren]

Hi,

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

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

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

[Elijah Newren]

On Mon, Oct 30, 2023 at 9:24 AM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> 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

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

[Elijah Newren]

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.

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

[Junio C Hamano]

Elijah Newren <newren@gmail.com> writes:

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

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

[Phillip Wood]

Hi brian

Thanks for the re-roll, this version looks good to me

Phillip

On 30/10/2023 16:26, brian m. carlson 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(-)
> 
> 

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

[Martin Ågren]

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.

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

> +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(-)

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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

On 2023-10-31 at 21:48:57, Martin Ågren wrote:
> 
> 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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> writes:

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

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

[Junio C Hamano]

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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On 2023-11-01 at 03:44:30, Junio C Hamano wrote:
> "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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[brian m. carlson]

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

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

[brian m. carlson]

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

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.

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

[brian m. carlson]

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

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

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

[Junio C Hamano]

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

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

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

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

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

[Martin Ågren]

On Wed, 1 Nov 2023 at 20:24, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> 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

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

[Martin Ågren]

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

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?

[1] https://lore.kernel.org/git/xmqqo7ge2xzl.fsf@gitster.g/


Martin

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]

On 2023-11-02 at 08:53:36, Martin Ågren wrote:
> 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.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Martin Ågren]

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:

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

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

[Junio C Hamano]

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.