Getting the full path of a conflicting file within a custom merge driver?

Getting the full path of a conflicting file within a custom merge driver?

[Gondek, Andreas]

Hello,

I'm wondering if there is no option to find out the full path of a conflicting file from within a custom merge driver? If I understand this correctly, Git only provides the name of the 3 temporary local files and the size of the limiter. But is there any possibility to get the path of the file via a Git command, that I can run from within the merge driver? Maybe as part of the repository's status?

Thank you in advance.

Greetings,
Andreas Gondek
Applications
________________________________

Deutsche WertpapierService Bank AG
ITTAS
Derendorfer Allee 2
40476 Düsseldorf
Tel.: +49 69 5099 9503
Fax: +49 69 5099 85 9503
E-Mail: Andreas.Gondek@dwpbank.de
http://www.dwpbank.de

Deutsche WertpapierService Bank AG | Wildunger Straße 14 | 60487 Frankfurt am Main 
Sitz der AG: Frankfurt am Main, HRB 56913 | USt.-ID: DE 813759005 
Vorstand: Thomas Klanten, Dr. Christian Tonnesen
Aufsichtsrat: Wilfried Groos (Vors.)

Re: Getting the full path of a conflicting file within a custom merge driver?

[Junio C Hamano]

"Gondek, Andreas" <Andreas.Gondek@dwpbank.de> writes:

> I'm wondering if there is no option to find out the full path of a
> conflicting file from within a custom merge driver? If I understand
> this correctly, Git only provides the name of the 3 temporary local
> files and the size of the limiter. But is there any possibility to get
> the path of the file via a Git command, that I can run from within the
> merge driver? Maybe as part of the repository's status?

Short answer is "no", as the merge driver interface was originally
designed for a backend that can do its job with only the contents of
the three variants without any other information.  Imagine the
interface to things like "merge" from the RCS suite where it takes
three variants as the input---for them, the same three-tuple of
original, mine and theirs contents should merge to identical result
no matter where in the working tree the conflicts happened.

Having said that, I do not think it is unreasonable to feed more
information to external merge driver, perhaps by adding a new
environment variable GIT_MERGE_CONFLICTED_PATH exported when the
driver is run, or something.

AW: Getting the full path of a conflicting file within a custom merge driver?

[Gondek, Andreas]

Hi,

thank you for responding this fast. I would suggest providing this information as an additional parameter (like %A %O %B and %L) maybe %P. I think this would cost about 2 lines of code und wouldn't be any performance issue I assume. If I got it right in the source code, the information is present in the place where the parameters for the merge driver are prepared.

Greetings,

Andreas Gondek
Applications
________________________________

Deutsche WertpapierService Bank AG
ITTAS
Derendorfer Allee 2
40476 Düsseldorf
Tel.: +49 69 5099 9503
Fax: +49 69 5099 85 9503
E-Mail: Andreas.Gondek@dwpbank.de
http://www.dwpbank.de

Deutsche WertpapierService Bank AG | Wildunger Straße 14 | 60487 Frankfurt am Main 
Sitz der AG: Frankfurt am Main, HRB 56913 | USt.-ID: DE 813759005 
Vorstand: Thomas Klanten, Dr. Christian Tonnesen
Aufsichtsrat: Wilfried Groos (Vors.)

-----Ursprüngliche Nachricht-----
Von: Junio C Hamano [mailto:jch2355@gmail.com] Im Auftrag von Junio C Hamano
Gesendet: Montag, 1. Juni 2015 18:46
An: Gondek, Andreas
Cc: git@vger.kernel.org
Betreff: Re: Getting the full path of a conflicting file within a custom merge driver?

"Gondek, Andreas" <Andreas.Gondek@dwpbank.de> writes:

> I'm wondering if there is no option to find out the full path of a 
> conflicting file from within a custom merge driver? If I understand 
> this correctly, Git only provides the name of the 3 temporary local 
> files and the size of the limiter. But is there any possibility to get 
> the path of the file via a Git command, that I can run from within the 
> merge driver? Maybe as part of the repository's status?

Short answer is "no", as the merge driver interface was originally designed for a backend that can do its job with only the contents of the three variants without any other information.  Imagine the interface to things like "merge" from the RCS suite where it takes three variants as the input---for them, the same three-tuple of original, mine and theirs contents should merge to identical result no matter where in the working tree the conflicts happened.

Having said that, I do not think it is unreasonable to feed more information to external merge driver, perhaps by adding a new environment variable GIT_MERGE_CONFLICTED_PATH exported when the driver is run, or something.

Re: AW: Getting the full path of a conflicting file within a custom merge driver?

[Junio C Hamano]

"Gondek, Andreas" <Andreas.Gondek@dwpbank.de> writes:

> thank you for responding this fast. I would suggest providing this
> information as an additional parameter (like %A %O %B and %L) maybe
> %P.

Yes, per-cent plus a letter is more in line with the way information
is passed to the scripts already.  Thanks for making a more sensible
counter-suggestion.  And your %P(ath) sounds like a sensible choice.

It won't be a two-liner, though, as the path is an arbitrary string,
unlike the names of the three temporary files, and needs to be
quoted for the shell.

Let me see if I can find time today to cook up something.

Re*: AW: Getting the full path of a conflicting file within a custom merge driver?

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> "Gondek, Andreas" <Andreas.Gondek@dwpbank.de> writes:
>
>> thank you for responding this fast. I would suggest providing this
>> information as an additional parameter (like %A %O %B and %L) maybe
>> %P.
>
> Yes, per-cent plus a letter is more in line with the way information
> is passed to the scripts already.  Thanks for making a more sensible
> counter-suggestion.  And your %P(ath) sounds like a sensible choice.
>
> It won't be a two-liner, though, as the path is an arbitrary string,
> unlike the names of the three temporary files, and needs to be
> quoted for the shell.
>
> Let me see if I can find time today to cook up something.

I had this in my outbox but then forgot to send it out.

-- >8 --
Subject: ll-merge: pass the original path to external drivers

The interface to custom low-level merge driver was modeled to be
capable of driving programs like "merge" (from the RCS suite) that
can produce result solely by looking at three files that hold
contents of common ancestor, ours and theirs.  The information we
feed to the external drivers via the command line placeholders %O,
%A, and %B were designed to be purely about contents by giving
names of the temporary files that hold these variants without
exposing the original pathname.  No matter where the result goes,
merging the same three variants should produce the same result,
contents is the king, that is the Git way.

The external driver interface, however, is meant to help people to
step outside the Git worldview, and sometimes people want to know
the final path that the resulting merged contents would be stored
in.  Expose this to the external drivers via a new placeholder %P.

Requested-by: Andreas Gondek
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * t6026 is ancient and its style may need to be modernised to use
   test_cmp intead of cmp, etc.

 Documentation/gitattributes.txt |  5 ++++-
 ll-merge.c                      | 10 ++++++++--
 t/t6026-merge-attr.sh           | 14 +++++++++-----
 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 70899b3..81fe586 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -774,7 +774,7 @@ To define a custom merge driver `filfre`, add a section to your
 ----------------------------------------------------------------
 [merge "filfre"]
 	name = feel-free merge driver
-	driver = filfre %O %A %B
+	driver = filfre %O %A %B %L %P
 	recursive = binary
 ----------------------------------------------------------------
 
@@ -800,6 +800,9 @@ merge between common ancestors, when there are more than one.
 When left unspecified, the driver itself is used for both
 internal merge and the final merge.
 
+The merge driver can learn the pathname in which the merged result
+will be stored via placeholder `%P`.
+
 
 `conflict-marker-size`
 ^^^^^^^^^^^^^^^^^^^^^^
diff --git a/ll-merge.c b/ll-merge.c
index 8ea03e5..fc3c049 100644
--- a/ll-merge.c
+++ b/ll-merge.c
@@ -9,6 +9,7 @@
 #include "xdiff-interface.h"
 #include "run-command.h"
 #include "ll-merge.h"
+#include "quote.h"
 
 struct ll_merge_driver;
 
@@ -166,17 +167,20 @@ static int ll_ext_merge(const struct ll_merge_driver *fn,
 {
 	char temp[4][50];
 	struct strbuf cmd = STRBUF_INIT;
-	struct strbuf_expand_dict_entry dict[5];
+	struct strbuf_expand_dict_entry dict[6];
+	struct strbuf path_sq = STRBUF_INIT;
 	const char *args[] = { NULL, NULL };
 	int status, fd, i;
 	struct stat st;
 	assert(opts);
 
+	sq_quote_buf(&path_sq, path);
 	dict[0].placeholder = "O"; dict[0].value = temp[0];
 	dict[1].placeholder = "A"; dict[1].value = temp[1];
 	dict[2].placeholder = "B"; dict[2].value = temp[2];
 	dict[3].placeholder = "L"; dict[3].value = temp[3];
-	dict[4].placeholder = NULL; dict[4].value = NULL;
+	dict[4].placeholder = "P"; dict[4].value = path_sq.buf;
+	dict[5].placeholder = NULL; dict[5].value = NULL;
 
 	if (fn->cmdline == NULL)
 		die("custom merge driver %s lacks command line.", fn->name);
@@ -210,6 +214,7 @@ static int ll_ext_merge(const struct ll_merge_driver *fn,
 	for (i = 0; i < 3; i++)
 		unlink_or_warn(temp[i]);
 	strbuf_release(&cmd);
+	strbuf_release(&path_sq);
 	return status;
 }
 
@@ -269,6 +274,7 @@ static int read_merge_config(const char *var, const char *value, void *cb)
 		 *    %A - temporary file name for our version.
 		 *    %B - temporary file name for the other branches' version.
 		 *    %L - conflict marker length
+		 *    %P - the original path (safely quoted for the shell)
 		 *
 		 * The external merge driver should write the results in the
 		 * file named by %A, and signal that it has done with zero exit
diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh
index 3c21938..04c0509 100755
--- a/t/t6026-merge-attr.sh
+++ b/t/t6026-merge-attr.sh
@@ -85,11 +85,12 @@ test_expect_success 'retry the merge with longer context' '
 cat >./custom-merge <<\EOF
 #!/bin/sh
 
-orig="$1" ours="$2" theirs="$3" exit="$4"
+orig="$1" ours="$2" theirs="$3" exit="$4" path=$5
 (
 	echo "orig is $orig"
 	echo "ours is $ours"
 	echo "theirs is $theirs"
+	echo "path is $path"
 	echo "=== orig ==="
 	cat "$orig"
 	echo "=== ours ==="
@@ -110,7 +111,7 @@ test_expect_success 'custom merge backend' '
 
 	git reset --hard anchor &&
 	git config --replace-all \
-	merge.custom.driver "./custom-merge %O %A %B 0" &&
+	merge.custom.driver "./custom-merge %O %A %B 0 %P" &&
 	git config --replace-all \
 	merge.custom.name "custom merge driver for testing" &&
 
@@ -121,7 +122,7 @@ test_expect_success 'custom merge backend' '
 	o=$(git unpack-file master^:text) &&
 	a=$(git unpack-file side^:text) &&
 	b=$(git unpack-file master:text) &&
-	sh -c "./custom-merge $o $a $b 0" &&
+	sh -c "./custom-merge $o $a $b 0 'text'" &&
 	sed -e 1,3d $a >check-2 &&
 	cmp check-1 check-2 &&
 	rm -f $o $a $b
@@ -131,7 +132,7 @@ test_expect_success 'custom merge backend' '
 
 	git reset --hard anchor &&
 	git config --replace-all \
-	merge.custom.driver "./custom-merge %O %A %B 1" &&
+	merge.custom.driver "./custom-merge %O %A %B 1 %P" &&
 	git config --replace-all \
 	merge.custom.name "custom merge driver for testing" &&
 
@@ -148,9 +149,12 @@ test_expect_success 'custom merge backend' '
 	o=$(git unpack-file master^:text) &&
 	a=$(git unpack-file anchor:text) &&
 	b=$(git unpack-file master:text) &&
-	sh -c "./custom-merge $o $a $b 0" &&
+	sh -c "./custom-merge $o $a $b 0 'text'" &&
 	sed -e 1,3d $a >check-2 &&
 	cmp check-1 check-2 &&
+	sed -e 1,3d -e 4q $a >check-3 &&
+	echo "path is text" >expect &&
+	cmp expect check-3 &&
 	rm -f $o $a $b
 '
 

AW: Re*: AW: Getting the full path of a conflicting file within a custom merge driver?

[Gondek, Andreas]

Thanks, thanks, thanks.

One last question. If I don't want to compile Git myself, how long may the pu branch take approx. to get into a next release?

Mit freundlichen Grüßen

Andreas Gondek
Applications
________________________________

Deutsche WertpapierService Bank AG
ITTAS
Derendorfer Allee 2
40476 Düsseldorf
Tel.: +49 69 5099 9503
Fax: +49 69 5099 85 9503
E-Mail: Andreas.Gondek@dwpbank.de
http://www.dwpbank.de

Deutsche WertpapierService Bank AG | Wildunger Straße 14 | 60487 Frankfurt am Main 
Sitz der AG: Frankfurt am Main, HRB 56913 | USt.-ID: DE 813759005 
Vorstand: Thomas Klanten, Dr. Christian Tonnesen
Aufsichtsrat: Wilfried Groos (Vors.)

-----Ursprüngliche Nachricht-----
Von: Junio C Hamano [mailto:jch2355@gmail.com] Im Auftrag von Junio C Hamano
Gesendet: Freitag, 5. Juni 2015 00:11
An: Gondek, Andreas
Cc: git@vger.kernel.org
Betreff: Re*: AW: Getting the full path of a conflicting file within a custom merge driver?

Junio C Hamano <gitster@pobox.com> writes:

> "Gondek, Andreas" <Andreas.Gondek@dwpbank.de> writes:
>
>> thank you for responding this fast. I would suggest providing this 
>> information as an additional parameter (like %A %O %B and %L) maybe 
>> %P.
>
> Yes, per-cent plus a letter is more in line with the way information 
> is passed to the scripts already.  Thanks for making a more sensible 
> counter-suggestion.  And your %P(ath) sounds like a sensible choice.
>
> It won't be a two-liner, though, as the path is an arbitrary string, 
> unlike the names of the three temporary files, and needs to be quoted 
> for the shell.
>
> Let me see if I can find time today to cook up something.

I had this in my outbox but then forgot to send it out.

-- >8 --
Subject: ll-merge: pass the original path to external drivers

The interface to custom low-level merge driver was modeled to be capable of driving programs like "merge" (from the RCS suite) that can produce result solely by looking at three files that hold contents of common ancestor, ours and theirs.  The information we feed to the external drivers via the command line placeholders %O, %A, and %B were designed to be purely about contents by giving names of the temporary files that hold these variants without exposing the original pathname.  No matter where the result goes, merging the same three variants should produce the same result, contents is the king, that is the Git way.

The external driver interface, however, is meant to help people to step outside the Git worldview, and sometimes people want to know the final path that the resulting merged contents would be stored in.  Expose this to the external drivers via a new placeholder %P.

Requested-by: Andreas Gondek
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * t6026 is ancient and its style may need to be modernised to use
   test_cmp intead of cmp, etc.

 Documentation/gitattributes.txt |  5 ++++-
 ll-merge.c                      | 10 ++++++++--
 t/t6026-merge-attr.sh           | 14 +++++++++-----
 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 70899b3..81fe586 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -774,7 +774,7 @@ To define a custom merge driver `filfre`, add a section to your
 ----------------------------------------------------------------
 [merge "filfre"]
 	name = feel-free merge driver
-	driver = filfre %O %A %B
+	driver = filfre %O %A %B %L %P
 	recursive = binary
 ----------------------------------------------------------------
 
@@ -800,6 +800,9 @@ merge between common ancestors, when there are more than one.
 When left unspecified, the driver itself is used for both  internal merge and the final merge.
 
+The merge driver can learn the pathname in which the merged result will 
+be stored via placeholder `%P`.
+
 
 `conflict-marker-size`
 ^^^^^^^^^^^^^^^^^^^^^^
diff --git a/ll-merge.c b/ll-merge.c
index 8ea03e5..fc3c049 100644
--- a/ll-merge.c
+++ b/ll-merge.c
@@ -9,6 +9,7 @@
 #include "xdiff-interface.h"
 #include "run-command.h"
 #include "ll-merge.h"
+#include "quote.h"
 
 struct ll_merge_driver;
 
@@ -166,17 +167,20 @@ static int ll_ext_merge(const struct ll_merge_driver *fn,  {
 	char temp[4][50];
 	struct strbuf cmd = STRBUF_INIT;
-	struct strbuf_expand_dict_entry dict[5];
+	struct strbuf_expand_dict_entry dict[6];
+	struct strbuf path_sq = STRBUF_INIT;
 	const char *args[] = { NULL, NULL };
 	int status, fd, i;
 	struct stat st;
 	assert(opts);
 
+	sq_quote_buf(&path_sq, path);
 	dict[0].placeholder = "O"; dict[0].value = temp[0];
 	dict[1].placeholder = "A"; dict[1].value = temp[1];
 	dict[2].placeholder = "B"; dict[2].value = temp[2];
 	dict[3].placeholder = "L"; dict[3].value = temp[3];
-	dict[4].placeholder = NULL; dict[4].value = NULL;
+	dict[4].placeholder = "P"; dict[4].value = path_sq.buf;
+	dict[5].placeholder = NULL; dict[5].value = NULL;
 
 	if (fn->cmdline == NULL)
 		die("custom merge driver %s lacks command line.", fn->name); @@ -210,6 +214,7 @@ static int ll_ext_merge(const struct ll_merge_driver *fn,
 	for (i = 0; i < 3; i++)
 		unlink_or_warn(temp[i]);
 	strbuf_release(&cmd);
+	strbuf_release(&path_sq);
 	return status;
 }
 
@@ -269,6 +274,7 @@ static int read_merge_config(const char *var, const char *value, void *cb)
 		 *    %A - temporary file name for our version.
 		 *    %B - temporary file name for the other branches' version.
 		 *    %L - conflict marker length
+		 *    %P - the original path (safely quoted for the shell)
 		 *
 		 * The external merge driver should write the results in the
 		 * file named by %A, and signal that it has done with zero exit diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh index 3c21938..04c0509 100755
--- a/t/t6026-merge-attr.sh
+++ b/t/t6026-merge-attr.sh
@@ -85,11 +85,12 @@ test_expect_success 'retry the merge with longer context' '
 cat >./custom-merge <<\EOF
 #!/bin/sh
 
-orig="$1" ours="$2" theirs="$3" exit="$4"
+orig="$1" ours="$2" theirs="$3" exit="$4" path=$5
 (
 	echo "orig is $orig"
 	echo "ours is $ours"
 	echo "theirs is $theirs"
+	echo "path is $path"
 	echo "=== orig ==="
 	cat "$orig"
 	echo "=== ours ==="
@@ -110,7 +111,7 @@ test_expect_success 'custom merge backend' '
 
 	git reset --hard anchor &&
 	git config --replace-all \
-	merge.custom.driver "./custom-merge %O %A %B 0" &&
+	merge.custom.driver "./custom-merge %O %A %B 0 %P" &&
 	git config --replace-all \
 	merge.custom.name "custom merge driver for testing" &&
 
@@ -121,7 +122,7 @@ test_expect_success 'custom merge backend' '
 	o=$(git unpack-file master^:text) &&
 	a=$(git unpack-file side^:text) &&
 	b=$(git unpack-file master:text) &&
-	sh -c "./custom-merge $o $a $b 0" &&
+	sh -c "./custom-merge $o $a $b 0 'text'" &&
 	sed -e 1,3d $a >check-2 &&
 	cmp check-1 check-2 &&
 	rm -f $o $a $b
@@ -131,7 +132,7 @@ test_expect_success 'custom merge backend' '
 
 	git reset --hard anchor &&
 	git config --replace-all \
-	merge.custom.driver "./custom-merge %O %A %B 1" &&
+	merge.custom.driver "./custom-merge %O %A %B 1 %P" &&
 	git config --replace-all \
 	merge.custom.name "custom merge driver for testing" &&
 
@@ -148,9 +149,12 @@ test_expect_success 'custom merge backend' '
 	o=$(git unpack-file master^:text) &&
 	a=$(git unpack-file anchor:text) &&
 	b=$(git unpack-file master:text) &&
-	sh -c "./custom-merge $o $a $b 0" &&
+	sh -c "./custom-merge $o $a $b 0 'text'" &&
 	sed -e 1,3d $a >check-2 &&
 	cmp check-1 check-2 &&
+	sed -e 1,3d -e 4q $a >check-3 &&
+	echo "path is text" >expect &&
+	cmp expect check-3 &&
 	rm -f $o $a $b
 '
 

Re: Re*: AW: Getting the full path of a conflicting file within a custom merge driver?

[Christian Couder]

On Fri, Jun 5, 2015 at 7:56 AM, Gondek, Andreas
<Andreas.Gondek@dwpbank.de> wrote:
> Thanks, thanks, thanks.
>
> One last question. If I don't want to compile Git myself, how long may the pu branch take approx. to get into a next release?

According to:

https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt

"One release cycle for a feature release is expected to last for eight
to ten weeks."

As v2.4.2 was tagged on May 26, the next feature release should be in
6 to 9 weeks, and will hopefully include the feature you are
interested in.

(Also please don't top post on this list.)

Best,
Christian.

Re: Re*: AW: Getting the full path of a conflicting file within a custom merge driver?

[Christian Couder]

On Fri, Jun 5, 2015 at 10:07 AM, Christian Couder
<christian.couder@gmail.com> wrote:
> On Fri, Jun 5, 2015 at 7:56 AM, Gondek, Andreas
> <Andreas.Gondek@dwpbank.de> wrote:
>> Thanks, thanks, thanks.
>>
>> One last question. If I don't want to compile Git myself, how long may the pu branch take approx. to get into a next release?
>
> According to:
>
> https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt
>
> "One release cycle for a feature release is expected to last for eight
> to ten weeks."

Actually I should have read the next lines that say:

"- Maintenance releases are numbered as vX.Y.Z and are meant to
contain only bugfixes for the corresponding vX.Y.0 feature release and
earlier maintenance releases vX.Y.W (W < Z)."

> As v2.4.2 was tagged on May 26, the next feature release should be in
> 6 to 9 weeks, and will hopefully include the feature you are
> interested in.

The last feature release was v2.4.0 that was tagged on April 30, so
the next one should be in 3 to 5 weeks.

Re: AW: Re*: AW: Getting the full path of a conflicting file within a custom merge driver?

[Junio C Hamano]

"Gondek, Andreas" <Andreas.Gondek@dwpbank.de> writes:

> One last question. If I don't want to compile Git myself, how long may
> the pu branch take approx. to get into a next release?

There is no general estimate; not all topics necessarily graduate to
the released version.

I'd leave it on the list (and in 'pu') for a few days so that other
people can poke a hole in it for me to fix or improve it.  And then
it will hopefully merged to 'next' for further testing by other
people.  It may graduate to 'master' before the pre-release feature
freeze for the next cycle in which case it will be in 2.5; otherwise
it may have to wait for the release after that.

We are at the end of week #5 (cf. http://tinyurl.com/gitCal), and
the pre-release feature freeze is expected to happen end of this
month during week #9 this cycle.  Given that the patch is reasonably
simple and straightforward, I'd say we will have it in 2.5 scheduled
for mid next month.