2009/4/3 Jeremiah Dodds <jeremiah.do...@gmail.com>: > > > On Thu, Apr 2, 2009 at 9:02 PM, andrew cooke <and...@acooke.org> wrote: >> >> Echo wrote: >> > 2009/4/2 Jeremiah Dodds <jeremiah.do...@gmail.com> >> > >> >> The one thing that makes me want to use git more than any other dvcs is >> >> that you don't have to create a new directory for branches. This may be >> >> possible in other dvcs's , but git is the only one I've seen advertise >> >> the >> >> capability. >> [...] >> > That is the main reason why I switched to git at my work. >> > As for the git rebase, I don't ever plan on using that 'feature'. Even >> > though I would rather have had GvR pick git, I think he did a good job >> > deciding. > It looks like basically the same thing is accomplishable in hg, but is a bit > discouraged (I am not experienced with hg, and haven't read the docs > thoroughly, so I could be off base here). In most (d)vcs's , there is > normally a one-to-one relationship between project branches and directories > on your filesystem. In git, there is normally a many-to-on relationship > between project branches and directories on your filesystem - branching is > cheap and easy, and you can branch for every little fix or feature you want > to do, keeping one directory with multiple logical development paths with > basically no pain. > > > -- > http://mail.python.org/mailman/listinfo/python-list > >
I don't think it's discouraged at all. There are several ways to accomplish a similar workflow if you want a quick, short-lived branch. The ones I know of, are named branches, bookmarks, and mercurial queues. I have a hard time wrapping my head around what all of these (and git branching) mean, since a quick branch is something I rarely need in my personal development. The differences between each approach is very difficult for me to see. But they all let you have one set of files and work on disparate things at once to merge later. Queues (which is a patch stack) seem useful but also dangerous, since you can do a lot of switching back and forth without actually commiting. Since you can apply any of the queues to your working directory, they might work well for a short lived feature that you potentially put into a real branch or into the main if the feature is more complete and less experimental. Named branches work off of a changeset I believe. At any time you can rename the current branch, commit new stuff from that point in history, and you have a new branch; using the name to keep track of where you are. If you want to switch branches, you just update the working copy to be the new branch you want to work from. There are probably some advantages to how git handles things, considering this is the main feature I hear cited at something git does certifiably better, but I wouldn't know what that would be. Oh, and merc recently got a rebase as well, for good or ill. -- http://mail.python.org/mailman/listinfo/python-list
