On Sat, 16 Apr 2005, Petr Baudis wrote: > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter > where Petr Baudis <[EMAIL PROTECTED]> told me that... > > git branch --- creates a branch from a given commit > > (when passed empty commit, creates a branch > > from the current commit and sets the working > > tree to that branch) > > Note that there is a bug in current git update - it will allow you to > > bring several of your trees to follow the same branch, or even a remote > > branch. This is not even supposed to work, and will be fixed when I get > > some sleep. You will be able to do git pull even on local branches, and > > the proper solution for this will be just tracking the branch you want > > to follow. > > I must admit that I'm not entirely decided yet, so I'd love to hear your > opinion. > > I'm wondering, whether each tree should be fixed to a certain branch. > That is, you decide a name when you do git fork, and then the tree > always follows that branch. (It always has to follow [be bound to] > *some* branch, and each branch can be followed by only a single tree at > a time.)
I don't think I'm following the use of branches. Currently, what I do is have a git-pasky and a git-linus, and fork off a working directory from one of these for each thing I want to work on. I do some work, commit as I make progress, and then do a diff against the remote head to get a patch to send off. If I want to do a series of patches which depend on each other, I fork my next directory off of my previous one rather than off of a remote base. I haven't done much rebasing, so I haven't worked out how I would do that most effectively. I think I can make this space efficient by hardlinking unmodified blobs to a directory of cached expanded blobs. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html