Re: Merge conflicts are reported relative to root not cwd

From: Eric Deplagne <eric@deplagne.name>
Date: Apr 14, 2016, 07:53 UTC
Message-ID: <20160414075300.GA16358@mail.eric.deplagne.name>
In-Reply-To: <xmqq4mb5jhm7.fsf@gitster.mtv.corp.google.com>

On Wed, 13 Apr 2016 14:58:40 -0700, Junio C Hamano wrote:

Show 29 quoted lines

> 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.

  From my use of git, I'd really love to be able to copy/paste 
  ../../../../../../builtin/fetch.c to some vi (or anything else) 
  command line instead of having vi (or whatever) bark that
  it does not know where builtin/fetch.c is.

-- 
  Eric Deplagne