Re: [PATCH v2 1/1] merge-file: add an option to process object IDs
- From
- Martin Ågren <martin.agren@gmail.com>
- Date
- Oct 31, 2023, 21:48 UTC
- Message-ID
- <20231031214859.25293-1-martin.agren@gmail.com>
- In-Reply-To
- <20231030162658.567523-2-sandals@crustytoothpaste.net>
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(-)
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