{"thread":{"id":"9586","subject":"[RFC] git-mergetool: show original branch names when possible","startedAt":"2007-08-20T07:53:18Z","lastAt":"2007-08-21T21:17:47Z","messageCount":8,"participants":["Jeff King","Junio C Hamano","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51057","messageId":"20070820075318.GA12478@coredump.intra.peff.net","threadId":"9586","inReplyTo":null,"subject":"[RFC] git-mergetool: show original branch names when possible","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-20T07:53:18Z","receivedAt":"2007-08-20T07:53:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The actual branch names are used when naming temporary files\nand when presenting the files to the user, instead of\ncalling them \"local\" and \"remote\".\n\nThe \"local\" branch name is gathered by dereferencing HEAD.\n\nThe \"remote\" branch name is placed in MERGE_HEAD by\ngit-merge.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nI have several uncertainties in the implementation:\n\n1. Is it OK to place the extra branch name information in MERGE_HEAD\nafter the SHA1?\n\n2. It looks like doing an anonymous 'git-pull' leaves GITHEAD_* as the\ncommit sha1, which means you will end up with that sha1 rather than\n'REMOTE', which is less nice than the current behavior. However, I think\nthat is fixable at the 'git-merge' level to produce a nicer name for the\nremote.\n\n3. This is meant to work similar to the GITHEAD_* feature, but needs to\nwork without using the environment. Many other scripts use GITHEAD_*,\nbut not MERGE_HEAD, so perhaps MERGE_HEAD is not the best place for\nthis.\n\nIt would be _really_ convenient in this case if we had a \"git is in the\nmiddle of something\" file, which has been discussed before. Clearly\nthere are some operations that persist across multiple command\ninvocations, and it would be nice rather than every command knowing\nabout every other command's implementation patterns (\"Oh, you have a\n.dotest file? You must be in the middle of...\") to have a single place\nwith something like:\n\n  $ cat .git/STATE\n  operation: merge\n  remote: git://git.kernel.org/pub/scm/git/git.git\n  branch: master\n  branch: octopus\n\n  $ cat .git/STATE\n  operation: rebase\n  upstream: origin/master\n  onto: HEAD~20\n\nwhere you could have arbitrary keys through which to communicate. Most\ncommand would just look at 'operation' (e.g., if operation == merge,\ndon't start a new merge), but some could use the information (which\nwould otherwise be lost) to work more usefully (e.g., git-mergetool\nunderstands remote and branch keys created by git-merge).\n\nThoughts?\n\n git-merge.sh     |    2 +-\n git-mergetool.sh |   24 ++++++++++++++++--------\n 2 files changed, 17 insertions(+), 9 deletions(-)\n\ndiff --git a/git-merge.sh b/git-merge.sh\nindex 5ccf282..e899801 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -477,7 +477,7 @@ then\n else\n \tfor remote\n \tdo\n-\t\techo $remote\n+\t\techo $remote $(eval echo \\$GITHEAD_$remote)\n \tdone >\"$GIT_DIR/MERGE_HEAD\"\n \tprintf '%s\\n' \"$merge_msg\" >\"$GIT_DIR/MERGE_MSG\"\n fi\ndiff --git a/git-mergetool.sh b/git-mergetool.sh\nindex 47a8055..8bc0a66 100755\n--- a/git-mergetool.sh\n+++ b/git-mergetool.sh\n@@ -151,8 +151,16 @@ merge_file () {\n     fi\n \n     BACKUP=\"$path.BACKUP.$$\"\n-    LOCAL=\"$path.LOCAL.$$\"\n-    REMOTE=\"$path.REMOTE.$$\"\n+    local_branch=$(\n+      git-symbolic-ref HEAD 2>/dev/null \\\n+        | sed -e 's#^refs/[^/]*/##' \\\n+        | sed -e 's/[^A-Za-z0-9]/-/g')\n+    LOCAL=\"$path.${local_branch:-HEAD}.$$\"\n+    remote_branch=$(\n+      sed -ne '1s/^[0-9a-f]* //p' \\\n+        <\"$GIT_DIR/MERGE_HEAD\" \\\n+        | sed -e 's/[^A-Za-z0-9]/-/g')\n+    REMOTE=\"$path.${remote_branch:-REMOTE}.$$\"\n     BASE=\"$path.BASE.$$\"\n \n     mv -- \"$path\" \"$BACKUP\"\n@@ -168,23 +176,23 @@ merge_file () {\n \n     if test -z \"$local_mode\" -o -z \"$remote_mode\"; then\n \techo \"Deleted merge conflict for '$path':\"\n-\tdescribe_file \"$local_mode\" \"local\" \"$LOCAL\"\n-\tdescribe_file \"$remote_mode\" \"remote\" \"$REMOTE\"\n+\tdescribe_file \"$local_mode\" \"${local_branch:-HEAD}\" \"$LOCAL\"\n+\tdescribe_file \"$remote_mode\" \"${remote_branch:-remote}\" \"$REMOTE\"\n \tresolve_deleted_merge\n \treturn\n     fi\n \n     if is_symlink \"$local_mode\" || is_symlink \"$remote_mode\"; then\n \techo \"Symbolic link merge conflict for '$path':\"\n-\tdescribe_file \"$local_mode\" \"local\" \"$LOCAL\"\n-\tdescribe_file \"$remote_mode\" \"remote\" \"$REMOTE\"\n+\tdescribe_file \"$local_mode\" \"${local_branch:-HEAD}\" \"$LOCAL\"\n+\tdescribe_file \"$remote_mode\" \"${remote_branch:-remote}\" \"$REMOTE\"\n \tresolve_symlink_merge\n \treturn\n     fi\n \n     echo \"Normal merge conflict for '$path':\"\n-    describe_file \"$local_mode\" \"local\" \"$LOCAL\"\n-    describe_file \"$remote_mode\" \"remote\" \"$REMOTE\"\n+    describe_file \"$local_mode\" \"${local_branch:-HEAD}\" \"$LOCAL\"\n+    describe_file \"$remote_mode\" \"${remote_branch:-remote}\" \"$REMOTE\"\n     printf \"Hit return to start merge resolution tool (%s): \" \"$merge_tool\"\n     read ans\n \n-- \n1.5.3.rc5.844.g67b3-dirty\n"},{"id":"51061","messageId":"7vabsmtxsg.fsf@gitster.siamese.dyndns.org","threadId":"9586","inReplyTo":"20070820075318.GA12478@coredump.intra.peff.net","subject":"Re: [RFC] git-mergetool: show original branch names when possible","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-20T08:28:31Z","receivedAt":"2007-08-20T08:28:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> 1. Is it OK to place the extra branch name information in MERGE_HEAD\n> after the SHA1?\n\nI do not think of anything that would barf offhand (we already\ndo that in FETCH_HEAD), but this would definitely be carefully\naudited.\n\n> 2. It looks like doing an anonymous 'git-pull' leaves GITHEAD_* as the\n> commit sha1, which means you will end up with that sha1 rather than\n> 'REMOTE', which is less nice than the current behavior.\n\nMuch less nice indeed.\n\n> It would be _really_ convenient in this case if we had a \"git is in the\n> middle of something\" file, which has been discussed before.\n> ...\n> there are some operations that persist across multiple command\n> invocations, and it would be nice rather than every command knowing\n> about every other command's implementation patterns (\"Oh, you have a\n> .dotest file? You must be in the middle of...\") to have a single place\n> with something like:\n>\n>   $ cat .git/STATE\n>   operation: merge\n>   remote: git://git.kernel.org/pub/scm/git/git.git\n>   branch: master\n>   branch: octopus\n\nIt would be very nice, and I would encourage any wannabe\nPorcelain writers to go wild on this.  One worry I have is if we\nwould need to support nested states.  \"I was in the middle of\n'foo' and then had to go sideways to do 'bar' which I am now in\nthe middle of\" kind of thing.\n"},{"id":"51070","messageId":"20070820085246.GA23764@coredump.intra.peff.net","threadId":"9586","inReplyTo":"7vabsmtxsg.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] git-mergetool: show original branch names when possible","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-20T08:52:47Z","receivedAt":"2007-08-20T08:52:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 20, 2007 at 01:28:31AM -0700, Junio C Hamano wrote:\n\n> I do not think of anything that would barf offhand (we already\n> do that in FETCH_HEAD), but this would definitely be carefully\n> audited.\n\nI didn't say it up front, but I think this is definitely post-1.5.3\nmaterial. :)\n\n> > 2. It looks like doing an anonymous 'git-pull' leaves GITHEAD_* as the\n> > commit sha1, which means you will end up with that sha1 rather than\n> > 'REMOTE', which is less nice than the current behavior.\n> \n> Much less nice indeed.\n\nI think this is a failing of git-merge, though, for not including that\nnice human-readable information. We can fix it with something like this:\n\n-- >8 --\n\ndiff --git a/git-merge.sh b/git-merge.sh\nindex e899801..742e15d 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -477,7 +477,14 @@ then\n else\n \tfor remote\n \tdo\n-\t\techo $remote $(eval echo \\$GITHEAD_$remote)\n+\t\tfriendly_name=$(eval echo \\$GITHEAD_$remote)\n+\t\tif echo $friendly_name | egrep -q '[0-9a-f]{40}'; then\n+\t\t\tfriendly_name=$(\n+\t\t\t  sed -ne \"s/$friendly_name\t//p\" \\\n+\t\t\t  <\"$GIT_DIR/FETCH_HEAD\" 2>/dev/null\n+\t\t\t)\n+\t\tfi\n+\t\techo $remote \"$friendly_name\"\n \tdone >\"$GIT_DIR/MERGE_HEAD\"\n \tprintf '%s\\n' \"$merge_msg\" >\"$GIT_DIR/MERGE_MSG\"\n fi\n\n-- 8< --\n\nBut probably it should wait for a better communications channel for\ncross-command state.\n\n> It would be very nice, and I would encourage any wannabe\n> Porcelain writers to go wild on this.  One worry I have is if we\n> would need to support nested states.  \"I was in the middle of\n> 'foo' and then had to go sideways to do 'bar' which I am now in\n> the middle of\" kind of thing.\n\nIt's just a stack, so I think you could implement it as a linked\nlist, with STATE being the head of the list, and each STATE file you\nwrite pointing to the previous one (which you rename when pushing).\n\nI might try to work on this, but definitely not tonight.\n\n-Peff\n"},{"id":"51105","messageId":"20070820181725.GB8542@efreet.light.src","threadId":"9586","inReplyTo":"20070820085246.GA23764@coredump.intra.peff.net","subject":"Re: [RFC] git-mergetool: show original branch names when possible","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-08-20T18:17:25Z","receivedAt":"2007-08-20T18:17:25Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Aug 20, 2007 at 04:52:47 -0400, Jeff King wrote:\n> On Mon, Aug 20, 2007 at 01:28:31AM -0700, Junio C Hamano wrote:\n> > > 2. It looks like doing an anonymous 'git-pull' leaves GITHEAD_* as the\n> > > commit sha1, which means you will end up with that sha1 rather than\n> > > 'REMOTE', which is less nice than the current behavior.\n> > \n> > Much less nice indeed.\n> \n> I think this is a failing of git-merge, though, for not including that\n> nice human-readable information. We can fix it with something like this:\n\nMaybe you could call git-name-rev on it if it does not come with\na human-readable name.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"51151","messageId":"20070821061014.GB7323@coredump.intra.peff.net","threadId":"9586","inReplyTo":"20070820181725.GB8542@efreet.light.src","subject":"Re: [RFC] git-mergetool: show original branch names when possible","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-21T06:10:14Z","receivedAt":"2007-08-21T06:10:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 20, 2007 at 08:17:25PM +0200, Jan Hudec wrote:\n\n> > I think this is a failing of git-merge, though, for not including that\n> > nice human-readable information. We can fix it with something like this:\n> \n> Maybe you could call git-name-rev on it if it does not come with\n> a human-readable name.\n\nI considered that, but it has two drawbacks:\n\n  1. It does not handle pulls which have no tracking branch (the only\n     ref we have is FETCH_HEAD, which is not a useful name :) ).\n\n  2. In some circumstances, it can come up with counter-intuitive\n     names. If more than one ref points to a given commit, then you can\n     end up with something like \"git-merge foo\" telling you all about\n     the merge conflicts with \"bar\". But perhaps that is too obscure a\n     corner case to worry about.\n\n-Peff\n"},{"id":"51169","messageId":"20070821145943.GI8542@efreet.light.src","threadId":"9586","inReplyTo":"20070821061014.GB7323@coredump.intra.peff.net","subject":"Re: [RFC] git-mergetool: show original branch names when possible","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-08-21T14:59:43Z","receivedAt":"2007-08-21T14:59:43Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Aug 21, 2007 at 02:10:14 -0400, Jeff King wrote:\n> On Mon, Aug 20, 2007 at 08:17:25PM +0200, Jan Hudec wrote:\n> \n> > > I think this is a failing of git-merge, though, for not including that\n> > > nice human-readable information. We can fix it with something like this:\n> > \n> > Maybe you could call git-name-rev on it if it does not come with\n> > a human-readable name.\n> \n> I considered that, but it has two drawbacks:\n> \n>   1. It does not handle pulls which have no tracking branch (the only\n>      ref we have is FETCH_HEAD, which is not a useful name :) ).\n\nIf there's no useful name, than it's probably hard to do anything at all\nabout it. Though FETCH_HEAD is not all that useless -- it at least says it is\nthat that you pull.\n\n>   2. In some circumstances, it can come up with counter-intuitive\n>      names. If more than one ref points to a given commit, then you can\n>      end up with something like \"git-merge foo\" telling you all about\n>      the merge conflicts with \"bar\". But perhaps that is too obscure a\n>      corner case to worry about.\n\nI meant it as a fallback, for cases where it for some reason can't be\nrecorded or is not recorded. Recording it is obviously better.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"51199","messageId":"20070821205503.GA16777@coredump.intra.peff.net","threadId":"9586","inReplyTo":"20070821145943.GI8542@efreet.light.src","subject":"Re: [RFC] git-mergetool: show original branch names when possible","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-21T20:55:03Z","receivedAt":"2007-08-21T20:55:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 21, 2007 at 04:59:43PM +0200, Jan Hudec wrote:\n\n> >   1. It does not handle pulls which have no tracking branch (the only\n> >      ref we have is FETCH_HEAD, which is not a useful name :) ).\n> \n> If there's no useful name, than it's probably hard to do anything at all\n> about it. Though FETCH_HEAD is not all that useless -- it at least says it is\n> that that you pull.\n\nBut there _is_ a useful name, it's just not a ref (it's the information\nfrom FETCH_HEAD \"branch 'foo' of git://...\"). In this case,\ngit-mergetool could pull it out of FETCH_HEAD, as well, but I feel like\nwe're starting to make a lot of fragile cross-tool assumptions.\n\n> I meant it as a fallback, for cases where it for some reason can't be\n> recorded or is not recorded. Recording it is obviously better.\n\nRight, in which case I think we should just be more complete about\nrecording it.\n\n-Peff\n"},{"id":"51203","messageId":"7vir78oadg.fsf@gitster.siamese.dyndns.org","threadId":"9586","inReplyTo":"20070821205503.GA16777@coredump.intra.peff.net","subject":"Re: [RFC] git-mergetool: show original branch names when possible","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-21T21:17:47Z","receivedAt":"2007-08-21T21:17:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Aug 21, 2007 at 04:59:43PM +0200, Jan Hudec wrote:\n>\n>> >   1. It does not handle pulls which have no tracking branch (the only\n>> >      ref we have is FETCH_HEAD, which is not a useful name :) ).\n>> \n>> If there's no useful name, than it's probably hard to do anything at all\n>> about it. Though FETCH_HEAD is not all that useless -- it at least says it is\n>> that that you pull.\n>\n> But there _is_ a useful name, it's just not a ref (it's the information\n> from FETCH_HEAD \"branch 'foo' of git://...\"). In this case,\n> git-mergetool could pull it out of FETCH_HEAD, as well, but I feel like\n> we're starting to make a lot of fragile cross-tool assumptions.\n\nIsn't the label \"FETCH_HEAD\" itself clear enough, without even\nlooking at it to see which commit it is?\n"}]}