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
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 
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
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 
(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 
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" .
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
For more options, visit https://groups.google.com/groups/opt_out.