Re: Merge conflicts are reported relative to root not cwd

[Stefan Beller <sbeller@google.com>]

On Wed, Apr 13, 2016 at 2:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> $ cd t/
>> $ git merge ...
>> ...
>> Auto-merging builtin/submodule--helper.c
>> Auto-merging builtin/fetch.c
>> CONFLICT (content): Merge conflict in builtin/fetch.c
>> Auto-merging builtin/clone.c
>> Auto-merging README.md
>> ...
>>
>> It should say ../builtin/fetch.c IMHO.
>> Any reason to keep the old behavior?
>
> I actually prefer to see the "relative to root" behaviour when it
> comes to things like this, that lets you view the things that happen
> in the whole-tree context.
>
> I would have to go insane before I start a whole-tree operation like
> "git merge" from deep in my tree, but if I happened to do that, e.g.
>
>         cd perl/blib/lib/Git/SVN/Memoize
>         git merge other-branch
>
> I'd rather see that the conflicted path, e.g. builtin/fetch.c,
> reported by showing it like the above output, not happening in
> ../../../../../../builtin/fetch.c which I have to count the
> up-dots to know which file it is talking about.
>

* In most trees you would still know which file is referred to, as
   there are no /$PATH/builtin/fetch.c files except for PATH=<empty>
   So I'd see that as a minor issue.

* This is your preference for whole-tree operations. What are
   whole-tree operations? (Is there a concise definition?
   Are submodules whole tree operations?)
   These questions are motivated by origin/sb/submodule-path-misc-bugs
   which a) fixes bugs and b) makes submodule handling consistent to the
   relative-to-cwd philosophy. As most submodule commands touch all
   submodules in the tree, we could argue it is a whole-tree operation, and
   you'd like to see submodule paths from the root level, too.

I'd like to avoid adding confusion here. So is there a an easy way to tell apart
which commands you would expect to use relative-to-cwd and which use
relative-to-root?