On 24/02/2009, at 6:10 AM, Bryan Ischo wrote:
It's not the ability to modify a single file in two different places at once. It's the ability to keep changes logically separated by directory, in a persistent manner that doesn't require git commands to put changes away and bring them back, that I care about. I find it infinitely easier to keep track of what I am doing by persistently retaining directory contents than by having a single working view and everything else being stashed away to be retrieved later.
I apologise if I'm missing something, but what's the difference between "cd ../branch" and "git checkout branch"? The state of your "working directory" is changed. You still have only one view of the directory. You can obviously view files in the other directory, but that's also possible with git, albeit somewhat harder if using a file manager. There are many GUI front-ends that allow you to quickly look at other branches and commits. What's the between "ls project-root" and "git branch"? Both list the "branches", both allow you to switch to that branch (cd, git checkout). I really don't see the difference, besides a clean project directory, in git's case.
One example of where git stash is more cumbersome is if you've created new files but haven't added them to the index yet. You have to add them to the index before you can stash. Now this is not a huge deal, but it does require more work to prep your tree for a stash than simply cd'ing out to another branch directory would take. There may be other cases where more work is involved in stashing (above and beyond having to actually run the git stash commands and maintain the list of stashes) than is involved in using locally stored branches, but I haven't used git stash enough to discover them. It would not surprise me to learn that there are lots of subtle details to be aware of when using git stash.
This is a bit of an annoyance, but it probably has more to do with workflow and discipline rather than git. You could leave that file there without tracking it at all, as long as the same file doesn't exist in another branch. However, this would be bad, since it's not "attached" to any branch and could get confusing. Before `git stash` came about, people just used `git commit -a -m "WIP something"`, which is pretty much all `git stash` does, except in a different... ref list I suppose. In this edge-case it's a bit more work to change to a different branch, but I think it only encourages to use the SCM properly.
Parallel branch directories have an advantage over git's branch views whenever you need to compare the contents of branches.
False. As mentioned earlier there are GUI tools which make this simple. If you don't like GUIs, you can use the command line equivalents (most tools execute git commands anyway). I don't know what these are since I've never had the need to compare two branches beyond `git diff`.
Maybe it's because I'm an emacs [...] [and] keeping track of [...] what sequence of [...] commands I need [...] is just more mental effort than I want to undertake.
*cheap shot alert* You use emacs, yet remembering commands is too much of an effort? I know I twisted your words a lot, and I'm not hating on emacs, but you have to admit that that is somewhat hypocritical.
I find it so much easier to just leave a branch subdirectory and when I return to it later, it is guaranteed to be exactly as it was when I left, without any effort on my part. If I am working on 4 or 5 bugs in parallel (which I have certainly done at work, where working on just 1 or 2 bugs at once would be inefficient because of the downtime associated with building each tree) I can't even imagine using git stashes to sanely keep track of everything.
This is exactly what branches are for. The exact same thing can be said for git branches. It's guaranteed to be exactly as it was when you switched to another branch. `git stash` should only be used when something is not ready to be committed, but you _urgently_ need to do something else, like a bug fix on the maintenance branch.
- Lack of rename tracking. Yeah, I know, git claims that it can do it after the fact when examining change histories but I've tried various scenarios and it just doesn't work very well, and even when it does, requires stupidly complex options to git commands to enable git to discover renames in the history correctly
I can't think of a situation where the file name is relevant. Even when renaming...
The problem comes when someone, in a branch, renames a file, and then tries to merge their changes into another branch in which the file was not renamed.
This would only be a problem if the file was not only renamed, but also _changed_, and significantly at that. In this case git would only see that, say, 60% of the file content was moved. I'm not sure how merging would work, since I have never worked on a branch when a file was moved (and changed) in another.
Unless file renames are tracked, the merge becomes very difficult.
Not at all. If git sees that the file content was _moved_ (not changed), it should be able to figure that out easily. Again, I haven't actually done this, but I don't see why it wouldn't work. I would suggest asking about this on #git (or the git ML). If it is indeed a problem then file a bug. I'm sure Linus would be happy to comment on it ;).
Refactoring a subsystem on a 'workbranch' is something that is done sometimes on large projects, and with git, I would expect that to be basically impossible to do sanely. Even if git's 'detect renames while examining history' technique did work, it still makes renames cumbersome, because you can't rename a file and change its contents at the same time or else git has almost no chance of detecting the rename via history. And if you can't change a file and rename it at the same time, then you can't, for example, properly rename a Java class, because the class name and file name have to be the same.
Why not? If you change the file contents and rename it, then obviously you'd also change the class name. Why else would you rename it?
It just shouldn't be that hard.
Why not? I can't imagine other SCMs doing this any better. If a file contents changes drastically, it doesn't matter if the name of the file is tracked. The name of the file is irrelevant. A merge conflict would arise even if the file was never renamed. I don't mean to contradict everything you say, it's just that I haven't had the same experience with git as you. Using git has been amazing. It does everything I want, it's sophisticated, it merges code well, and it has some very powerful features (like rebase). By the way, Mercurial seems faster than Bazaar (though I haven't used either much), and both are written in Python. Mercurial might not be pure python though, I am unsure.