Merge conflicts are reported relative to root not cwd

Merge conflicts are reported relative to root not cwd

[Stefan Beller]

$ 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?

Thanks,
Stefan

Re: Merge conflicts are reported relative to root not cwd

[Junio C Hamano]

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.

Re: Merge conflicts are reported relative to root not cwd

[Stefan Beller]

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?

Re: Merge conflicts are reported relative to root not cwd

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> * .... What are
>    whole-tree operations?

"git merge" does not let you merge "changes just in my current
directory".  You only merge the whole tree, and you can get
conflicts from all over the tree, not just in your current
directory.

Re: Merge conflicts are reported relative to root not cwd

[Jeff King]

On Wed, Apr 13, 2016 at 03:18:24PM -0700, Stefan Beller wrote:

> * 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?

I think some operations are fundamentally whole-tree. You do not merge a
subtree, but create a new top-level commit. Similarly, even in:

  cd Documentation
  git log -p .

the diffs we see still show the whole path. We are traversing the whole
tree.

If you are touching all submodules with an operation, I'd expect it to
show full paths, not relative ones. But then I set status.relativePaths
to "false", so maybe I am in the minority.

-Peff

Re: Merge conflicts are reported relative to root not cwd

[Stefan Beller]

On Wed, Apr 13, 2016 at 3:41 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Apr 13, 2016 at 03:18:24PM -0700, Stefan Beller wrote:
>
>> * 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?
>
> I think some operations are fundamentally whole-tree. You do not merge a
> subtree, but create a new top-level commit. Similarly, even in:
>
>   cd Documentation
>   git log -p .
>
> the diffs we see still show the whole path. We are traversing the whole
> tree.

Oh I see.

    cd dir-with-submodules
    git submodule update .

would traverse only that dir-with-submodules/ subtree from the users
POV.

>
> If you are touching all submodules with an operation, I'd expect it to
> show full paths, not relative ones. But then I set status.relativePaths
> to "false", so maybe I am in the minority.

That would be `git submodule foreach`. Any other submodule subcommand
is similar to git log as they default to the whole tree but can do similar stuff
as "git log -- dir/" for sub trees.

Having subcommands behave differently w.r.t. path being relative or not
sounds like an inconsistency to me. Currently they are all relative,
i.e. `git submodule foreach` breaks your expectation for displaying paths.

>
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Merge conflicts are reported relative to root not cwd

[Eric Deplagne]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

On Wed, 13 Apr 2016 14:58:40 -0700, Junio C Hamano 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.

  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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]