On Tue, Jun 9, 2009 at 2:59 PM, Scott Chacon<schacon@xxxxxxxxx> wrote: > * breaks the various things that 'checkout' does into separate > commands - moves 'revert' to doing what 'checkout -- path' does, moves > current 'revert' to 'cherry-pick --revert' (which someone mentioned > was a good idea at the last GitTogether), and adds 'unstage' for > 'reset HEAD file'. also adds a '-s' option to 'branch' to switch to > the branch after you create it, which many people expect rather than > 'checkout -b'. This would definitely make it easier to explain things to svn users. To be honest, I'm not convinced svn's use of the word "revert" is really right, though. Git's isn't *really* right either, since it actually makes a new commit, it doesn't remove the old one like it sounds like it does. Maybe 'reverse' would be a better name for what git does, and we should just introduce another word for what svn does. (With CVS, you just deleted the file and then did a checkout/update on it again, which made sense to me. That works in git too.) Crazy idea: we could actually make 'git revert' do both: given a commit, it applies the reverse as it does now. Given filenames, it simply brings them back to HEAD. But maybe that's too crazy. > * adds 'git resolved' for 'git add', which I hear all the time as > being confusing This one doesn't really do it for me. svn's need to "resolve" a file after removing its conflicts always annoyed me. Look, you can see I've screwed around with the file. The file contains no more conflicts. It's resolved, already! Maybe it's heresy, but I really liked CVS's way of dealing with this: if the file still has conflict markers in it, it's not resolved. If it doesn't, then it's resolved. Very hard to mess up. And I've definitely messed up (and known other people to mess up) with both svn's method and git's method, both of which allow you to commit files with conflict markers without getting warned. > * adds 'git publish' for creating a bare repo from your current repo > and scp/rsync-ing it to a server (which is nice if you're not using > GitHub/repo.or.cz where remote repo seeding is easier) Very cool, and this has been seriously hard to explain to people. I'm not even sure there *is* a good way to do this without running a series of several commands. > * adds 'git info' which shows a bunch of basic information about the > repo, which is actually pretty cool Less important to me, but sounds fine just due to svn compatibility. > * 'git push origin --delete <branch>' for 'git push origin :branch' This would help a lot of people too, I think. Although some might argue that "helping" them to delete branches is maybe not a great idea. Have fun, Avery -- 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