On Fri, Jul 15, 2011 at 8:42 PM, Ted Ts'o <tytso@xxxxxxx> wrote: > On Fri, Jul 15, 2011 at 09:44:21AM -0700, Linus Torvalds wrote: >> So I would like to repeat: I think our commit-date based hack has been >> pretty successful. We've lived with it for years and years. Even the >> "let's try to fix it by adding slop" code is from three years ago >> (commit 7d004199d1), which means that for three years we never really >> saw any serious problems. I forget what problem we actually did see - >> I have this dim memory of it being Ted that had problems with a merge >> because git picked a crap merge base, but that may just be my >> Alzheimer's speaking. > > My original main issue was simply that "git tag --contains" and "git > branch --contains" was either (a) incorrect, or (b) slower than > popping up gitk and pulling the information out of the GUI. The > reason for (b) is because of gitk.cache. > > Maybe the answer then is creating a command-line tool (it doesn't have to > be in "core" of git) which just pulls the dammned information out of > gitk.cache.... > > (Yes, it's gross, but I'm not worrying about the long-term > architecture of git or anything high-falutin' like that. I'm just a > poor dumb user who just wants git tag --contains and git branch > --contains to be fast and accurate...) If "git tag --contains" and "git branch --contains" give incorrect answers because the commiter date is wrong in some commits, then why not use "git replace" to "change" the commiter date in the commits that have a wrong date? Is it because you don't want to use "git replace", or because there is no script to do it automatically, or is there another reason? Thanks, Christian. -- 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