On Thu, Aug 23, 2012 at 02:40:19PM -0700, Junio C Hamano wrote: > > This last sentence confuses me. Now we are documenting that "yes, .. > > really means HEAD..HEAD, which is the empty range". But isn't the point > > of this patch to say "sure, it would be the empty range, but because > > that is stupid and pointless, we do not consider it valid and treat .. > > as a pathspec"? > > No, we still allow ".." as a short-hand for HEAD..HEAD when it is > understood as a rev. We also allow ".." as a pathspec to match the > parent directory when it is understood as a pathspec. > > The only thing the topic wanted to change was the disambiguation > logic. When a string S can name both rev and path, we ask the user > to disambiguate, but when S is "..", we do not have to (as one > interpretation is meaningless). Ah, right. OK, that makes more sense. I wasn't thinking that you could still do: git log .. -- if you really wanted to. So yeah, it doesn't belong here... > I think that documentation belongs to the section of disambiguation > without "--". Usually you need to use "--", but ".." is taken as > path even without "--". ...but I agree it would be worth mentioning there. But I am not sure where "there" is in the current documentation. > An interesting side effect is that > > git log .. pu > > used to error out for ".." being both rev and path, but it will > error out for "pu" not being a path in the working tree. This is > because on a command line without "--" disambiguation, once you > start listing paths, you have to have nothing but paths after that > point. Hmm. Yeah, that's a slightly surprising emergent behavior. But I think it is not a big deal since both cases led to errors anyway. -Peff -- 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