I do like that about git too, but I'm not sure what you mean about svn. Is there something in particular you can't do very easily from the terminal?
If you rename a file, for example, when using git, git isn't going to realise unless you explicitly git add the new file (or your IDE does so), unless I've missed something. (or you use git mv to rename it). So I don't know what you mean about it analysing the filesystem and figuring everything out. 2011/2/9 Cédric Beust ♔ <[email protected]>: > > > On Wed, Feb 9, 2011 at 1:57 PM, Fabrizio Giudici > <[email protected]> wrote: >> >> 2. For refactoring and renames, I use the IDE (NetBeans) that does all for >> me. Yes, with some occasional bug (talking of 6.9), but no dramatic ones. > > One of the many things I like about git is that it doesn't need any IDE > support to work correctly. SVN and P4 do need that to some extent (e.g. you > need to `p4 edit` a file before you can modify it). Git doesn't care: > modify, rename, delete, do whatever you have to do and do it wherever you > like (shell, IDE, emacs, etc..) and when you are ready to commit/push, git > will just look at your file system and it will be able to guess what you did > (most of the time). > >> >> 3. For what concerns rebase, I must confess I've not completely understood >> what it is (also after reading Reiner's post). I read "rewriting history"... >> how much is it different from the "squash commit" technique described by >> Fowler: http://martinfowler.com/bliki/MercurialSquashCommit.html? > > Rebasing (just like Git's index) is the kind of concept that seems quite > confusing at first, but when you get it, it's the most natural thing in the > world. > My attempt at describing it: most source control systems don't make any > distinction between public and private commits. As soon as you commit > something, it will be visible by everyone. With the index and rebasing, you > can actually separate the two. While you are working on a problem, you can > commit as often as you want, even when your code doesn't even compile or > doesn't pass the tests. It doesn't matter since you will get a chance to > modify these commits before pushing them to a public repository. This allows > you to work very incrementally. > Once you're happy with your change, you get a chance to review all your > private commits and merge them into one (or reorder them, or pretty much > whatever). Since you have commit messages for each of them, you also get a > pretty good idea of what you did and you can replace all these small > messages with a bigger one that is more descriptive while removing the > little implementation details that only you cared about during development. > So you turn these n little commits into a bigger one and you push it. It > becomes a second nature once you get used to this kind of flow. > And then, as you become more comfortable, you become more precise with your > rebases. For example, imagine you have 5 commits that mix up the fixes to > two different bugs. So you rebase and you turn commits 1, 3 and 5 into one > for bug 1 and commits 2 and 4 for bug 2. Rebase allows you to do pretty much > whatever you do with your history. > Just a few examples off the top of my head. > Git is a very exciting technology to work with once you start understanding > it. > -- > Cédric > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
