Re: git guidance

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Dec 8, 2007, 06:33 UTC
Message-ID: <46a038f90712072233v4ee1143cx68a82d15cfaa4402@mail.gmail.com>
In-Reply-To: <200712010950.15628.a1426z@gawab.com>

On Dec 1, 2007 7:50 PM, Al Boldi <a1426z@gawab.com> wrote:

> Not sure what you mean by operationally transparent?  It would be transparent
> for the updating client,  and the rest of the git-users would need to wait
> for the commit from the updating client; which is ok, as this transparency
> is not meant to change the server-side git-update semantic.

I guess what he means is that when your write to the file -- from your editor -- it can't be considered a commit. During an editing session you might write a dozen times, only to commit it once you are happy (that it compiles, passes tests, etc).

Show 5 quoted lines

> Sure, you wouldn't want to change the git-engine update semantics, as that
> sits on the server and handles all users.  But what the git model is
> currently missing is a client manager.  Right now, this is being worked
> around by replicating the git tree on the client, which still doesn't
> provide the required transparency.

If you want a dumb-ish client CVS-style, you can try git-cvsserver. But the git model is definitely superior -- "replicating the tree on the client" is not a workaround but a central strategy.

Have you used git and other DSCMs much? From your writing, it sounds like you may have misunderstood how some of the principles of git work out in practice.

cheers,