Thanks,
Rob

For example if I rename a file and modify it in the same commit there is no way to detect the renaming if not told explicitly.

Gábor: I tend to avoid defining people as ‘zealots’ even if they somewhat deserve it, as this puts the interlocutor in a defensive position and often leads to flames. Just say GIT-fans.

> people are used to having to tell thier source control systems
> this information and so its confusing that they don’t have to,
> but thats the reason there’s a git-rename command,

and then:

> these issues are equal whether you have ‘automatic’
> move discovery or explicit description.

imho this is not consistent.

on one hand, git-zealots say that you do not have to tell git that you’re renaming, because git is able to figure it out automatically,

on the other hand, when confrontend with a situation, where you EXPLICITLY HAVE TO TELL git that you’re renaming, otherwise it does not work, then in such situations they say: but that’s the same with other VCSs.

but doesn’t that means that their previous sentence is not correct?

please note, i’m not saying what git does is wrong. i just do not agree with the opinion, that git’s rename-handling is BETTER IN EVERY WAY.

in my opinion it’s a DIFFERENT approach. better in some ways, and worse in other ways.

I guess you could argue that people are used to having to tell thier source control systems this information and so its confusing that they don’t have to, but thats the reason there’s a git-rename command,

as far as i understand, Git’s storage model is simply unable to record file-renames, and there’s nothing wrong with that. Linus probably maid a decision, that other properties were more important.

what i don’t like, is when Git proponents starts to claim that this is in fact an advantage. and that’s completely incorrect, because, as you said, if your VCS stores more than what GIT stores, then it can still do GIT-style inference.

also, to all git-rename-zealots:

http://kerneltrap.org/node/11765

If I am using a version control system that tracks renames or copies, there is nothing stopping me from ignoring that tracking data and performing GIT-style inference. Such a VCS is storing a superset of the information needed for such a merge.

If a VCS has the opportunity to record developer intent w.r.t. moves and other operations, it seems like a no-brainer to do so. Not doing so limits your options in the future.

“I don’t think there are many misunderstandings… could you tell an example?”

and later said:

“also, when hunting for comparisons, be careful, because these programs are changing very fast. so it’s quite possible, that a comparison that’s let’s say 6 months old, is not obsolete.”

I think many misunderstandings arise for this very reason.

As to why people choose different VCSs, I think it has a lot to do with examples set and who wants to emulate whom.

That is, I think many people say, “Linus wrote git, so it must be great” or “Canonical sponsors bzr, so it is surely awesome.” and only later justify it by saying “I use git because it’s really fast” or “I use bzr so I don’t feel like I’m trapped inside a Kafka story.” (The middle ground, of course, is currently occupied by hg — reasonably fast and reasonably usable.)