On Fri, 9 Jan 2009, Len Brown wrote: > > I guess using 'git mv' gave me the false expectation > that git actually tracks moves like other SCMs > and it would show up that way in the diff -- though > now that I think about it, I like the comparison > of the two endpoints that git did even better. The main reason "git mv" exists at all is just people migrating from other places expecting it. It's largely just purely synthetic sugar - it has almost no meaning to git long-term. [ Technically, it _is_ meaningful, in that it obviously not just moves the file in the checked-out copy, but it also moves the index information around. So "git mv" clearly does something, but it's not important in the big picture. So using "git mv" is really nothing fundamental - it doesn't really matter to the end result, and if you had done the 'mv' by just applying a patch to delete the old file and create a new one, the actual commit would have been 100% identical. Think of it as a convenience function, and you won't be wrong. ] > gitk doesn't use --follow by default, and when it is added, the history > looks pretty strange. Heh. That's because "--follow" is a total hack, and doesn't do the nice (and pretty complicated) parent rewriting that the real "git log" family of operations normally do. So yeah, "--follow" is broken. It's really a quick hack there for people who come from some other SCM to feel more comfy with git. If you come from SVN or CVS, you never had proper history, and you never had "gitk" anyway, and so "gitk --follow" doesn't really work. But it makes the pure _textual_ logs look a bit like CVS/SVN. I'd love to make --follow work better and integrate more, but I've been so successful at never using it myself that I don't much care. And it really is not a very natural thing for git to do, so the hackiness is somewhat inherent. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
