On Sun, 20 Oct 2013 03:39:50 -0700 (PDT) Blake McBride <blake1...@gmail.com> wrote:
> Yes, of course, creating a totally new branch from where you are > doesn't cause any problems because nothing changes. > > The problem is that, I and likely most of the world, have a handful > of long-running branches - that already exist. A full rebuild is out > of the question when it takes two hours. I don't think I follow. Do you mean that you waht to develop your tentative fix on a branch forked off a "side branch" (meaning "not 'master'" and) and then integrate the ready fix into "master" meaning you'd need to do two checkouts and two full rebuilds to achieve the end result? If so, the answer is to use separate work trees. There are several ways to do that: 1. The most dumbed down but working just okay in terms of disk space on filesystems with sensible hardlinks (that is, not Windows) is to just clone the original repository and check out different branches in the "main" repository and in the clone. Unless you're using the "file://" scheme explicitly when doing such a "local cloning" Git is smart and hardlinks everything possible in the object database of the clone to the object database of the original repository, so almost no disk space gets wasted. The downside of this approach is that if you intend to keep this check out for a long time (I mean, to develop more than one fix) you will have to sync the clone both ways (push your work to the original repo and fetch its developments to the clone). This is both doable and nothing really special but you'll have to wrap your head around this concept. 2. If you're on a POSIX system, use the git-new-workdir script [1] which sets around a new work tree with its own .git subdirectory which links everything but the truly local stuff (like the HEAD ref file) to the original repository. This allows you to not clone anything and to literally share the single Git object database while having any number of branches checked out to separate work trees. This approach does not requires pushing and fetching (as there's only one common object store) but in return it requires careful thinking before committing: never commit on a branch if this same branch is currently checked out in another work tree sharing the same object store. 3. Play with environment variables and plumbing Git commands to semi-manually work with a separate index and the work tree. This is roughly the same as (2) but does not require any filesystem-level interlinking and hence should work even on Windows. I tried to explain to someone how this is supposed to work in [4] (not really tested). > I just took a look at GO. I previously thought it was Google's > replacement of GWT. No, it's a language. > These days all that matters are web apps. This is a very limited world view. But anyway the most visible area Go has traction in is web apps (see [3] for instance) because some people prefer to write their web apps using a language which is pleasure to work with. > Anything else can be written in C/C++. Sorry for being a bit harsh but people writing "C/C++" don't know *both* of these languages well enough but rather only one of them, and usually the one with "++" in its name, as those languages really are no less different than, say, C and Scheme; so it's plain ignorance. > In terms of parallel programming, there are some really good tools > for C/C++ such as silk. Sure, a typical case of "The Blub paradox" [2]. 1. https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir 2. http://c2.com/cgi/wiki?BlubParadox 3. http://talks.golang.org/2013/oscon-dl.slide 4. http://stackoverflow.com/a/18789418/720999 -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
