On Mon, 31 Jan 2011, Jeff King wrote: > On Mon, Jan 31, 2011 at 04:28:49PM -0500, Nicolas Pitre wrote: > > > So... we do suck at something? So why not take this opportunity to > > shake yourself out of this easy comfort and improve Git as a result on > > both front? :-) > > Yes, we do suck at rename following. The problem is that it is partially > an implementation issue, and partially a fundamental issue. Obviously > --follow sucks pretty hard right now, and that could be fixed. Namely it > follows only a single file, and it interacts very badly with history > simplification. This is no excuse not to do proper source tree reorganization. Telling people not to move files around because Git sucks at tracking them is also the wrong answer. > But even with those things fixed, there will still be annoyances. > > It will still be _slower_ to turn it on all the time, for one[1]. And > that's due to fundamental design decisions of the git data structure. > And I'm not knocking those decisions; I think they made the right > tradeoff. But that doesn't mean we don't pay the cost for that tradeoff. I agree. However sitting on our back and resisting a cleanup just because our very tool does poorly in that scenario is just like putting our heads in the sand and pretend that the problem doesn't exist. Better do what most people without internal knowledge of Git would do and just clean up the tree, and then benefit from this extraordinary opportunity of having this environment right at home where Git developers have a much greater incentive to work on this issue and improve things. > And no matter what your model, renames can be annoying. On-going topics > will have a painful rebase or merge. And people looking at history will > have to deal with the code-base having different names at different > points. Yeah, you can say it's all just "content", but the filenames we > put things in are actually useful. Of course. But such is life. Many projects out there are just like that, and facing this situation ourselves will just help us figure out ways to make Git even more useful to more people. > So I don't think it's wrong to say "renames are a pain, and so should > not be done lightly". I disagree. This is like saying: "renames are not well supported, so let's avoid them while using Git." People used to say that of merges with CVS. Are we going to follow suit de facto? Imagine the Git detractors taking our source tree mess to exemplify this Git flaw since "Git developers themselves are unwilling to move files around because Git sucks at it". > I do think it's wrong to say "renames can't be > done"; I just the cost needs to be considered. Instead, why not saying: "Rename tracking is not as optimal as it could be, so let's work it out." ? Nicolas -- 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