On Mon, Feb 23, 2009 at 1:11 PM, Bryan Ischo <bji-keyword-pacman.3644cb@www.ischo.com> wrote:
Aaron Griffin wrote:
On Sun, Feb 22, 2009 at 10:12 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
On 23/02/2009, at 12:57 PM, Bryan Ischo wrote:
OK, so I guess I really need to get into the habit of using git-rebase -i.
Yes, git rebase is one of the most wonderful things about git.
git rebase -i, git add -p, and git stash are my three most "omg awesome" git commands.
Just curious ... what's so awesome about git stash? It seems to me that it is only necessary because git doesn't support multiple branches in the same tree. The Perforce (and some DVCS systems like Bazaar) way is to root each branch at a different subdirectory of your repository top-level directory in your local filesystem. Then you can work on files in multiple branches simultaneously without having to 'switch' your view between them constantly, 'stashing' and 'unstashing' changes all the time.
I use git stash when switching back and forth between branches when I am of the mindset that "oh this isn't commit-able yet". I keep noticing you mention "multiple branches in the same tree", but am at a loss as to why that's necessary. git offers the same functionality, mainly due to the fact that a "git checkout" is as quick as a "cd". git co master ...change... commit git co branch-a ...change... commit ..change.. stash git co master git stash --apply commit I guess I can't think of a good use-case when you would want to edit foo.c from BOTH master and branch-a at the exact same time... it seems like an attention killer to me. Like watching two TVs at once or something. Could you explain why you would need the files side-by-side?
- A single branch-based 'view' that switches your files around in-place as you change which branch you are on, instead of keeping branches in separate subdirectories
See above - I don't get how this is a con, as branch switching in git is painfully quick
- 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
git is focused on file contents, and doesn't really care where those contents actually are. It seems odd to me too, but I have yet to discover a case when this is a big deal - I mean if I'm looking at some C code, I don't care if the file is named something.c or SOEMTHING.c or omgwtf.c - it's the code that matters.