On Mon, Feb 23, 2009 at 1:11 PM, Bryan Ischo <[email protected]> wrote: > Aaron Griffin wrote: >> >> On Sun, Feb 22, 2009 at 10:12 PM, Sebastian Nowicki <[email protected]> >> 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. _______________________________________________ pacman-dev mailing list [email protected] http://www.archlinux.org/mailman/listinfo/pacman-dev
