{"thread":{"id":"42022","subject":"Merge conflicts are reported relative to root not cwd","startedAt":"2016-04-13T21:37:31Z","lastAt":"2016-04-14T07:53:00Z","messageCount":7,"participants":["Stefan Beller","Junio C Hamano","Jeff King","Eric Deplagne"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"283411","messageId":"CAGZ79kbVfk=yAK3UB=H385_YfAtMHZe-gSE=EYVvvcS8jjy08A@mail.gmail.com","threadId":"42022","inReplyTo":null,"subject":"Merge conflicts are reported relative to root not cwd","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-04-13T21:37:31Z","receivedAt":"2016-04-13T21:37:31Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"$ cd t/\n$ git merge ...\n...\nAuto-merging builtin/submodule--helper.c\nAuto-merging builtin/fetch.c\nCONFLICT (content): Merge conflict in builtin/fetch.c\nAuto-merging builtin/clone.c\nAuto-merging README.md\n...\n\nIt should say ../builtin/fetch.c IMHO.\nAny reason to keep the old behavior?\n\nThanks,\nStefan\n"},{"id":"283417","messageId":"xmqq4mb5jhm7.fsf@gitster.mtv.corp.google.com","threadId":"42022","inReplyTo":"CAGZ79kbVfk=yAK3UB=H385_YfAtMHZe-gSE=EYVvvcS8jjy08A@mail.gmail.com","subject":"Re: Merge conflicts are reported relative to root not cwd","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-13T21:58:40Z","receivedAt":"2016-04-13T21:58:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> $ cd t/\n> $ git merge ...\n> ...\n> Auto-merging builtin/submodule--helper.c\n> Auto-merging builtin/fetch.c\n> CONFLICT (content): Merge conflict in builtin/fetch.c\n> Auto-merging builtin/clone.c\n> Auto-merging README.md\n> ...\n>\n> It should say ../builtin/fetch.c IMHO.\n> Any reason to keep the old behavior?\n\nI actually prefer to see the \"relative to root\" behaviour when it\ncomes to things like this, that lets you view the things that happen\nin the whole-tree context.\n\nI would have to go insane before I start a whole-tree operation like\n\"git merge\" from deep in my tree, but if I happened to do that, e.g.\n\n\tcd perl/blib/lib/Git/SVN/Memoize\n git merge other-branch\n\nI'd rather see that the conflicted path, e.g. builtin/fetch.c,\nreported by showing it like the above output, not happening in\n../../../../../../builtin/fetch.c which I have to count the\nup-dots to know which file it is talking about.\n"},{"id":"283421","messageId":"CAGZ79kZSyLZxMXSSv=uDpuA0zTUy6nU4vwEF5f7WLhoRp1hXig@mail.gmail.com","threadId":"42022","inReplyTo":"xmqq4mb5jhm7.fsf@gitster.mtv.corp.google.com","subject":"Re: Merge conflicts are reported relative to root not cwd","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-04-13T22:18:24Z","receivedAt":"2016-04-13T22:18:24Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Apr 13, 2016 at 2:58 PM, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>> $ cd t/\n>> $ git merge ...\n>> ...\n>> Auto-merging builtin/submodule--helper.c\n>> Auto-merging builtin/fetch.c\n>> CONFLICT (content): Merge conflict in builtin/fetch.c\n>> Auto-merging builtin/clone.c\n>> Auto-merging README.md\n>> ...\n>>\n>> It should say ../builtin/fetch.c IMHO.\n>> Any reason to keep the old behavior?\n>\n> I actually prefer to see the \"relative to root\" behaviour when it\n> comes to things like this, that lets you view the things that happen\n> in the whole-tree context.\n>\n> I would have to go insane before I start a whole-tree operation like\n> \"git merge\" from deep in my tree, but if I happened to do that, e.g.\n>\n> cd perl/blib/lib/Git/SVN/Memoize\n> git merge other-branch\n>\n> I'd rather see that the conflicted path, e.g. builtin/fetch.c,\n> reported by showing it like the above output, not happening in\n> ../../../../../../builtin/fetch.c which I have to count the\n> up-dots to know which file it is talking about.\n>\n\n* In most trees you would still know which file is referred to, as\n there are no /$PATH/builtin/fetch.c files except for PATH=\n So I'd see that as a minor issue.\n\n* This is your preference for whole-tree operations. What are\n whole-tree operations? (Is there a concise definition?\n Are submodules whole tree operations?)\n These questions are motivated by origin/sb/submodule-path-misc-bugs\n which a) fixes bugs and b) makes submodule handling consistent to the\n relative-to-cwd philosophy. As most submodule commands touch all\n submodules in the tree, we could argue it is a whole-tree operation, and\n you'd like to see submodule paths from the root level, too.\n\nI'd like to avoid adding confusion here. So is there a an easy way to tell apart\nwhich commands you would expect to use relative-to-cwd and which use\nrelative-to-root?\n"},{"id":"283428","messageId":"xmqqvb3li14k.fsf@gitster.mtv.corp.google.com","threadId":"42022","inReplyTo":"CAGZ79kZSyLZxMXSSv=uDpuA0zTUy6nU4vwEF5f7WLhoRp1hXig@mail.gmail.com","subject":"Re: Merge conflicts are reported relative to root not cwd","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-13T22:40:11Z","receivedAt":"2016-04-13T22:40:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> * .... What are\n> whole-tree operations?\n\n\"git merge\" does not let you merge \"changes just in my current\ndirectory\". You only merge the whole tree, and you can get\nconflicts from all over the tree, not just in your current\ndirectory.\n"},{"id":"283429","messageId":"20160413224129.GC10011@sigill.intra.peff.net","threadId":"42022","inReplyTo":"CAGZ79kZSyLZxMXSSv=uDpuA0zTUy6nU4vwEF5f7WLhoRp1hXig@mail.gmail.com","subject":"Re: Merge conflicts are reported relative to root not cwd","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-04-13T22:41:29Z","receivedAt":"2016-04-13T22:41:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 13, 2016 at 03:18:24PM -0700, Stefan Beller wrote:\n\n> * This is your preference for whole-tree operations. What are\n> whole-tree operations? (Is there a concise definition?\n> Are submodules whole tree operations?)\n> These questions are motivated by origin/sb/submodule-path-misc-bugs\n> which a) fixes bugs and b) makes submodule handling consistent to the\n> relative-to-cwd philosophy. As most submodule commands touch all\n> submodules in the tree, we could argue it is a whole-tree operation, and\n> you'd like to see submodule paths from the root level, too.\n> \n> I'd like to avoid adding confusion here. So is there a an easy way to tell apart\n> which commands you would expect to use relative-to-cwd and which use\n> relative-to-root?\n\nI think some operations are fundamentally whole-tree. You do not merge a\nsubtree, but create a new top-level commit. Similarly, even in:\n\n cd Documentation\n git log -p .\n\nthe diffs we see still show the whole path. We are traversing the whole\ntree.\n\nIf you are touching all submodules with an operation, I'd expect it to\nshow full paths, not relative ones. But then I set status.relativePaths\nto \"false\", so maybe I am in the minority.\n\n-Peff\n"},{"id":"283433","messageId":"CAGZ79kYt8M1CP_3T+VYmz2EGPAyfxOx2zTEugLyHL+GsiZ9RSg@mail.gmail.com","threadId":"42022","inReplyTo":"20160413224129.GC10011@sigill.intra.peff.net","subject":"Re: Merge conflicts are reported relative to root not cwd","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-04-13T22:52:53Z","receivedAt":"2016-04-13T22:52:53Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Apr 13, 2016 at 3:41 PM, Jeff King wrote:\n> On Wed, Apr 13, 2016 at 03:18:24PM -0700, Stefan Beller wrote:\n>\n>> * This is your preference for whole-tree operations. What are\n>> whole-tree operations? (Is there a concise definition?\n>> Are submodules whole tree operations?)\n>> These questions are motivated by origin/sb/submodule-path-misc-bugs\n>> which a) fixes bugs and b) makes submodule handling consistent to the\n>> relative-to-cwd philosophy. As most submodule commands touch all\n>> submodules in the tree, we could argue it is a whole-tree operation, and\n>> you'd like to see submodule paths from the root level, too.\n>>\n>> I'd like to avoid adding confusion here. So is there a an easy way to tell apart\n>> which commands you would expect to use relative-to-cwd and which use\n>> relative-to-root?\n>\n> I think some operations are fundamentally whole-tree. You do not merge a\n> subtree, but create a new top-level commit. Similarly, even in:\n>\n> cd Documentation\n> git log -p .\n>\n> the diffs we see still show the whole path. We are traversing the whole\n> tree.\n\nOh I see.\n\n cd dir-with-submodules\n git submodule update .\n\nwould traverse only that dir-with-submodules/ subtree from the users\nPOV.\n\n>\n> If you are touching all submodules with an operation, I'd expect it to\n> show full paths, not relative ones. But then I set status.relativePaths\n> to \"false\", so maybe I am in the minority.\n\nThat would be `git submodule foreach`. Any other submodule subcommand\nis similar to git log as they default to the whole tree but can do similar stuff\nas \"git log -- dir/\" for sub trees.\n\nHaving subcommands behave differently w.r.t. path being relative or not\nsounds like an inconsistency to me. Currently they are all relative,\ni.e. `git submodule foreach` breaks your expectation for displaying paths.\n\n>\n> -Peff\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"283437","messageId":"20160414075300.GA16358@mail.eric.deplagne.name","threadId":"42022","inReplyTo":"xmqq4mb5jhm7.fsf@gitster.mtv.corp.google.com","subject":"Re: Merge conflicts are reported relative to root not cwd","fromName":"Eric Deplagne","fromEmail":"eric@deplagne.name","sentAt":"2016-04-14T07:53:00Z","receivedAt":"2016-04-14T07:53:00Z","isPatch":false,"sender":{"key":"eric@deplagne.name","avatar":null},"body":"On Wed, 13 Apr 2016 14:58:40 -0700, Junio C Hamano wrote:\n> Stefan Beller writes:\n> \n> > $ cd t/\n> > $ git merge ...\n> > ...\n> > Auto-merging builtin/submodule--helper.c\n> > Auto-merging builtin/fetch.c\n> > CONFLICT (content): Merge conflict in builtin/fetch.c\n> > Auto-merging builtin/clone.c\n> > Auto-merging README.md\n> > ...\n> >\n> > It should say ../builtin/fetch.c IMHO.\n> > Any reason to keep the old behavior?\n> \n> I actually prefer to see the \"relative to root\" behaviour when it\n> comes to things like this, that lets you view the things that happen\n> in the whole-tree context.\n> \n> I would have to go insane before I start a whole-tree operation like\n> \"git merge\" from deep in my tree, but if I happened to do that, e.g.\n> \n> \tcd perl/blib/lib/Git/SVN/Memoize\n> git merge other-branch\n> \n> I'd rather see that the conflicted path, e.g. builtin/fetch.c,\n> reported by showing it like the above output, not happening in\n> ../../../../../../builtin/fetch.c which I have to count the\n> up-dots to know which file it is talking about.\n\n From my use of git, I'd really love to be able to copy/paste \n ../../../../../../builtin/fetch.c to some vi (or anything else) \n command line instead of having vi (or whatever) bark that\n it does not know where builtin/fetch.c is.\n\n-- \n Eric Deplagne\n"}]}