Johannes Sixt wrote: > Marcel M. Cary schrieb: >> * Change "git rev-parse --show-cdup" to print a full path instead of >> a series of "../" when it prints anything > > http://thread.gmane.org/gmane.comp.version-control.git/88557/focus=88562 > > I don't see that you bring in any new arguments. To be clear, as mentioned here: http://thread.gmane.org/gmane.comp.version-control.git/88557/focus=88573 I'm not talking about a situation where the symlink is in the working tree pointing outwards. I'm talking about a symlink outside pointing in. And as mentioned later in that thread, the --work-tree workaround doesn't actually work. One new thing I have to add is that the reason --show-cdup prints a correct path but pull fails is because it's the *shell* who misinterprets the path. So telling git rev-parse where the work-tree is helps nothing. It already knows. http://thread.gmane.org/gmane.comp.version-control.git/88557/focus=88581 So far I've seen no response to the idea, which Yves mentions, about trying to restrict the absolute path behavior to times when bash would interpret the "../" incorrectly. Nor have I seen a response to the idea of correcting the shell's behavior in cd_to_toplevel, for example by adding a "cd `pwd`", and I don't really understand the scenario where this would be a performance concern; I think I haven't found a particular discussion that several people have referenced. Perhaps I should prepare a patch for that so I can verify that it works as I expect and so we have something more concrete to discuss? Any tips on how to follow the reference 7vk5sly3h9.fsf@xxxxxxxxxxxxxxxxxxxxxxxx in the first url above? It looks to be about performance. Message-Id seems to not be indexed for searching. Marcel -- 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
