Jakub Narebski, Tue, Dec 18, 2007 22:24:26 +0100: > On Tue, 18 Dec 2007, Alex Riesen wrote: > > I think that we have parsing of the blob locators at the wrong level: > > so that git-show, git-log and git-diff can handle its pathnames as > > they handle path filters (relative to cwd), > > What cwd? <path> in <tree-ish>:<path> syntax is "relative" to <tree-ish>. But the act of running "git-show <tree-ish>:<path>" does have a working directory relative to the project root. And usually the relative directory makes a lot of sense in git-show commands. > What should git do in your proposal when we are on master branch in > Documentation subdirectory, and want to check TODO file in todo branch? > "git show todo:TODO" is most natural IMHO. Yes, and that's why I NAKed the patches in the mail to Dana. I just hope the problem gets some attention. Maybe I even get something out of it, maybe not. It is not that hard to keep the patches in my tree. > Note that for true <tree> as <tree-ish> you just don't know where > in the working area directory hierarchy <tree> can be. This means you > do't know relation of <tree> and <path> in <tree>:<path> to cwd. I understand. But... How often do you think people use git show with a tree which was not pointed by a commit? > > and git-cat-file, > > git-diff-tree, git-rev-list, etc can handle theirs always relative to > > the project root. > > Not "relative to project root". Relative to tree-ish used on right hand > side in <tree-ish>:<path> extended SHA-1 syntax. It is usually project > root, because when you specify <commit> or <tag> as <tree-ish> it refers > to top/root directory of a project. I know. My problem: it is also awkward. git-show :test-l<Tab>ib.sh just does not do what I expect. Nor does git cat-file HEAD:test-l<Tab>ib.sh. And git cat-file HEAD:t/test-l<Tab> does not work at all. And this is very simple example. Normally the pathnames are about 100 characters long. You know, it maybe as much correct as you wish, but is not very usable (and no, I can't use the contributed completion. For lots of reasons). > > I actually do not see any problem for git-show (being porcelain-level > > program) to treat *each and every* path anywhere relatively to the > > current directory. It is just more comfortable. > > This breaks backward compatibility, hard. And IMHO breaks layers. Maybe they should be broken in porcelain... > But if (big if) it was to be implemented, default behavior should be > unchanged, and relative to the cwd (layers!) should use new syntax, > for example > > $ cd $GIT/t > $ git show 570f32266:t/test-lib.sh # works > $ git show 570f32266:test-lib.sh # should not work Well... Frankly, I suggest changing this for porcelain-level commands (show and diff) and leave it as it is for plumbing. > $ git show 570f32266:./test-lib.sh # should work Definitely. I even implemented a patch to allow just this, but scraped it: it looked a bit small and the syntax is not obvious to the user. Maybe that is what I end up with, though. > $ git show 570f32266:/t/test-lib.sh # should perhaps work > Currently ":/<text>" (but not "<ref>:/<text>") is taken; see Yes, and it becomes more and more an obstacle. With just one user standing, AFAICS (/me considers Dscho's assassination for moment... Nah... Maybe poison?) - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
