See below:

On Sunday, October 20, 2013 12:56:45 PM UTC-5, Konstantin Khomoutov wrote:
> On Sun, 20 Oct 2013 03:39:50 -0700 (PDT) 
> Blake McBride < <javascript:>> 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. 

Damm that is interesting!  Well done for GIT!  That eliminates disk issues 
for me.  Knowing I need to do a clone of a clone is very helpful!

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

Even better!

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

Writing web apps is my least favorite programming to do (although, all 
programming is fun for me).  As a consequence of a long history, it is 
where I am.  I am happy you have a broader 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. 

Now that sure sounds different from all the things said about Java....

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

Having 30 years experience with C, I understand...
However, C and C++ share a lot in terms of build processes and dependencies.

> > 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]. 

I know what the Blub Paradox is, but I am not sure how you are applying it 
to my statement unless you mean to say silk is junk.

Did you ever notice that when you are driving down the highway, all of the 
people going slower than you are morons, and all of the people going 
faster than you are lunatics?  [Gallagher?]


> 1. 
> 2. 
> 3. 
> 4. 

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

Reply via email to