Bug#426938: git-core: Conflict markers should always have a SHA1
It's been a long time. Thanks huge for checking back! IIRC, my specific scenario was that I had accidentally committed with some unresolved conflict markers still in a large README file. Happens. :-) When I discovered the markers, much much later, I wanted to figure out which merge they had come from. I did of course figure it out, but it would have been much more convenient if I just had a handle on the commit ids of both sides of the merge. At least, that's the best I can remember. If you want to just close this bug, I'm cool with it. If I have more trouble I can always file another, and this time actually record my specific scenario. :-) I'd say that in general it should always be harmless to include the commit id anytime you print a symbolic revision id, and it might very occasionally be helpful. But it's no big deal, I think. Again, thanks for your time on this. Bart On Sat, Mar 12, 2011 at 12:57 PM, Jonathan Nieder jrnie...@gmail.com wrote: tags 426938 + moreinfo quit Hi again, 4 years ago, Bart Massey wrote[1]: As of now, the conflict markers generated by merges sometimes include only a relative symbolic name such as HEAD. A SHA1 should also always be included, so that months later the marker is still meaningful. My response was that it is not obvious what that would buy, given that conflict markers are supposed to be ephemeral things that do not make it into permanent history. That is, in order to change HEAD, you would need to run git merge --abort or git reset --merge first anyway. The conflict labels should be easy to change given a reason to do so, so I'm marking the bug accordingly. Thanks for your work. Jonathan [1] http://bugs.debian.org/426938 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#426938: git-core: Conflict markers should always have a SHA1
tags 426938 + moreinfo quit Hi again, 4 years ago, Bart Massey wrote[1]: As of now, the conflict markers generated by merges sometimes include only a relative symbolic name such as HEAD. A SHA1 should also always be included, so that months later the marker is still meaningful. My response was that it is not obvious what that would buy, given that conflict markers are supposed to be ephemeral things that do not make it into permanent history. That is, in order to change HEAD, you would need to run git merge --abort or git reset --merge first anyway. The conflict labels should be easy to change given a reason to do so, so I'm marking the bug accordingly. Thanks for your work. Jonathan [1] http://bugs.debian.org/426938 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#426938: git-core: Conflict markers should always have a SHA1
reassign 426938 git found 426938 git/1:1.7.1-1 tags 426938 + upstream quit Hi Bart, Sorry for the long silence. Bart Massey wrote: As of now, the conflict markers generated by merges sometimes include only a relative symbolic name such as HEAD. A SHA1 should also always be included, so that months later the marker is still meaningful. Wait --- why? Conflict markers are supposed to be ephemeral things: in order for the merge to be sanely resolved, the conflict markers should be replaced with a version reconciling the two changes. Example: git init /tmp/foo cd /tmp/foo git commit --allow-empty -m root git checkout -b branch echo this way is better the-way.txt git add -A git commit -m 'one way' git checkout master echo no, this way is better the-way.txt git add -A git commit -m 'other way' ! git merge branch cat the-way.txt produces HEAD no, this way is better === this way is better branch but if I try to ‘git commit’, I get: U the-way.txt fatal: 'commit' is not possible because you have unmerged files. I would be willing to write a patch to make conflict hunks unconditionally include a commit id, but I am not sure yet whether the added characters would be just noise. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#426938: git-core: Conflict markers should always have a SHA1
Package: git-core Version: 1:1.5.1.1-1 Severity: wishlist As of now, the conflict markers generated by merges sometimes include only a relative symbolic name such as HEAD. A SHA1 should also always be included, so that months later the marker is still meaningful. Bart Massey [EMAIL PROTECTED] -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (495, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages git-core depends on: ii libc6 2.5-7 GNU C Library: Shared libraries ii libcurl3-gnutls 7.15.5-1 Multi-protocol file transfer libra ii libdigest-sha1-perl 2.11-2 NIST SHA-1 message digest algorith ii liberror-perl 0.15-8 Perl module for error/exception ha ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li ii perl-modules 5.8.8-7Core Perl modules ii zlib1g1:1.2.3-13 compression library - runtime Versions of packages git-core recommends: ii curl 7.15.5-1 Get a file from an HTTP, HTTPS, FT pn git-doc none (no description available) ii less 394-4 Pager program similar to more ii openssh-client [ssh-client] 1:4.3p2-10 Secure shell client, an rlogin/rsh ii patch 2.5.9-4Apply a diff file to an original ii rsync 2.6.9-3fast remote file copy program (lik -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
