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 [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

   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.

Reply via email to