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
