* Merge conflicts are reported relative to root not cwd @ 2016-04-13 21:37 Stefan Beller 2016-04-13 21:58 ` Junio C Hamano 0 siblings, 1 reply; 7+ messages in thread From: Stefan Beller @ 2016-04-13 21:37 UTC (permalink / raw) To: git $ 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Merge conflicts are reported relative to root not cwd 2016-04-13 21:37 Merge conflicts are reported relative to root not cwd Stefan Beller @ 2016-04-13 21:58 ` Junio C Hamano 2016-04-13 22:18 ` Stefan Beller 2016-04-14 7:53 ` Eric Deplagne 0 siblings, 2 replies; 7+ messages in thread From: Junio C Hamano @ 2016-04-13 21:58 UTC (permalink / raw) To: Stefan Beller; +Cc: git 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Merge conflicts are reported relative to root not cwd 2016-04-13 21:58 ` Junio C Hamano @ 2016-04-13 22:18 ` Stefan Beller 2016-04-13 22:40 ` Junio C Hamano 2016-04-13 22:41 ` Jeff King 2016-04-14 7:53 ` Eric Deplagne 1 sibling, 2 replies; 7+ messages in thread From: Stefan Beller @ 2016-04-13 22:18 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Merge conflicts are reported relative to root not cwd 2016-04-13 22:18 ` Stefan Beller @ 2016-04-13 22:40 ` Junio C Hamano 2016-04-13 22:41 ` Jeff King 1 sibling, 0 replies; 7+ messages in thread From: Junio C Hamano @ 2016-04-13 22:40 UTC (permalink / raw) To: Stefan Beller; +Cc: git 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Merge conflicts are reported relative to root not cwd 2016-04-13 22:18 ` Stefan Beller 2016-04-13 22:40 ` Junio C Hamano @ 2016-04-13 22:41 ` Jeff King 2016-04-13 22:52 ` Stefan Beller 1 sibling, 1 reply; 7+ messages in thread From: Jeff King @ 2016-04-13 22:41 UTC (permalink / raw) To: Stefan Beller; +Cc: Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Merge conflicts are reported relative to root not cwd 2016-04-13 22:41 ` Jeff King @ 2016-04-13 22:52 ` Stefan Beller 0 siblings, 0 replies; 7+ messages in thread From: Stefan Beller @ 2016-04-13 22:52 UTC (permalink / raw) To: Jeff King; +Cc: Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Merge conflicts are reported relative to root not cwd 2016-04-13 21:58 ` Junio C Hamano 2016-04-13 22:18 ` Stefan Beller @ 2016-04-14 7:53 ` Eric Deplagne 1 sibling, 0 replies; 7+ messages in thread From: Eric Deplagne @ 2016-04-14 7:53 UTC (permalink / raw) To: Junio C Hamano; +Cc: Stefan Beller, git [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-04-14 8:35 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-13 21:37 Merge conflicts are reported relative to root not cwd Stefan Beller 2016-04-13 21:58 ` Junio C Hamano 2016-04-13 22:18 ` Stefan Beller 2016-04-13 22:40 ` Junio C Hamano 2016-04-13 22:41 ` Jeff King 2016-04-13 22:52 ` Stefan Beller 2016-04-14 7:53 ` Eric Deplagne
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.