# Merge conflicts are reported relative to root not cwd 7 messages from 2016-04-13 to 2016-04-14. Participants: Stefan Beller, Junio C Hamano, Jeff King, Eric Deplagne. Thread: https://gitlist.dev/t/42022 ## Stefan Beller, 2016-04-13 21:37 Subject: Merge conflicts are reported relative to root not cwd Message-ID: URL: https://gitlist.dev/e/CAGZ79kbVfk%3DyAK3UB%3DH385_YfAtMHZe-gSE%3DEYVvvcS8jjy08A%40mail.gmail.com ``` $ 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, 2016-04-13 21:58 Subject: Re: Merge conflicts are reported relative to root not cwd Message-ID: URL: https://gitlist.dev/e/xmqq4mb5jhm7.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Stefan Beller 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. ``` ## Stefan Beller, 2016-04-13 22:18 Subject: Re: Merge conflicts are reported relative to root not cwd Message-ID: URL: https://gitlist.dev/e/CAGZ79kZSyLZxMXSSv%3DuDpuA0zTUy6nU4vwEF5f7WLhoRp1hXig%40mail.gmail.com In-Reply-To: ``` On Wed, Apr 13, 2016 at 2:58 PM, Junio C Hamano wrote: > Stefan Beller 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= 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, 2016-04-13 22:40 Subject: Re: Merge conflicts are reported relative to root not cwd Message-ID: URL: https://gitlist.dev/e/xmqqvb3li14k.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Stefan Beller 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, 2016-04-13 22:41 Subject: Re: Merge conflicts are reported relative to root not cwd Message-ID: <20160413224129.GC10011@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160413224129.GC10011%40sigill.intra.peff.net In-Reply-To: ``` 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 ``` ## Stefan Beller, 2016-04-13 22:52 Subject: Re: Merge conflicts are reported relative to root not cwd Message-ID: URL: https://gitlist.dev/e/CAGZ79kYt8M1CP_3T%2BVYmz2EGPAyfxOx2zTEugLyHL%2BGsiZ9RSg%40mail.gmail.com In-Reply-To: <20160413224129.GC10011@sigill.intra.peff.net> ``` On Wed, Apr 13, 2016 at 3:41 PM, Jeff King 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 ``` ## Eric Deplagne, 2016-04-14 07:53 Subject: Re: Merge conflicts are reported relative to root not cwd Message-ID: <20160414075300.GA16358@mail.eric.deplagne.name> URL: https://gitlist.dev/e/20160414075300.GA16358%40mail.eric.deplagne.name In-Reply-To: ``` On Wed, 13 Apr 2016 14:58:40 -0700, Junio C Hamano wrote: > Stefan Beller 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 ```