threads / discuss / 42022

Merge conflicts are reported relative to root not cwd

Subject: Merge conflicts are reported relative to root not cwd

## tl;dr

7 messages between Apr 13, 2016 and Apr 14, 2016.

replies: 6people: 4as markdown or json

Stefan Beller· Apr 13, 2016, 21:37 UTC · lore

$ 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

Junio C Hamano· Apr 13, 2016, 21:58 UTC · re: Stefan Beller · lore

Re: Merge conflicts are reported relative to root not cwd

Stefan Beller <sbeller@google.com> writes:

Show 12 quoted lines

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

Stefan Beller· Apr 13, 2016, 22:18 UTC · re: Junio C Hamano · lore

Re: Merge conflicts are reported relative to root not cwd

On Wed, Apr 13, 2016 at 2:58 PM, Junio C Hamano <gitster@pobox.com> wrote:

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

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

Junio C Hamano· Apr 13, 2016, 22:40 UTC · re: Stefan Beller · lore

Re: Merge conflicts are reported relative to root not cwd

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.

Jeff King· Apr 13, 2016, 22:41 UTC · re: Stefan Beller · lore

Re: Merge conflicts are reported relative to root not cwd

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

Show 12 quoted lines

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

Stefan Beller· Apr 13, 2016, 22:52 UTC · re: Jeff King · lore

Re: Merge conflicts are reported relative to root not cwd

On Wed, Apr 13, 2016 at 3:41 PM, Jeff King <peff@peff.net> wrote:

Show 23 quoted lines

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

Show 6 quoted lines

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

Eric Deplagne· Apr 14, 2016, 07:53 UTC · re: Junio C Hamano · lore

Re: Merge conflicts are reported relative to root not cwd

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