Junio C Hamano <gits...@pobox.com> writes: > Junio C Hamano <gits...@pobox.com> writes: > >> I wonder if it makes more sense to always move to toplevel upfront >> and consistently use path from the toplevel, perhaps like the patch > > s/the patch/the attached patch/ I meant. > >> does. The first hunk is what you wrote but only inside MERGE_RR >> block, and the second hunk deals with converting end-user supplied >> paths that are relative to the original relative to the top-level. >> >> The tweaking of $orderfile you have in the first hunk may have to be >> tightened mimicking the way how "eval ... --sq ... ; shift" is used >> in the second hunk to avoid confusion in case orderfile specified by >> the end user happens to be the same as a valid revname >> (e.g. "master"). > > And here is a squash-able patch to illustrate what I mean.
By the way, I didn't think this through, but how is the orderfile that comes from the configuration file handled when it is not an absolute path? I think it is _wrong_ to take it as relative to where the user started the program. The -O<file> parameter from the command line, when <file> is not absolute, should be taken as relative to where the user _thinks_ s/he is, but when it comes from the diff.orderfile configuration and it is not absolute, it should be taken as relative to the top of the working tree. As we always cd_to_top with the suggested SQUASH, it means that the orderfile that came from the configuration does not have to be touched, while the orderfile given via -O<file> on the command line needs prefixing.
