Re: git guidance

Re: git guidance

[Jing Xue]

Quoting Al Boldi <a1426z@gawab.com>:

> Sure, browsing is the easy part, but Version Control starts when things
> become writable.

But how is that supposed to work?  What happens when you make some
changes to a file and save it?  Do you want the "git file system" to
commit it right aways or wait until you to issue a "commit" command?
The first behavior would obviously be wrong, and the second would make
the "file system" not operationally transparent anyways. Right?

By the way, the only SCM I have worked with that tries to mount its
repository (or a view on top of it) as a file system is ClearCase with
its dynamic views. And, between the buggy file system implementation,
the intrusion on workflow, and the lack of scalability, at least in
the organization I worked for, it turned out to be a horrible,
horrible, horrible idea.

Cheers.
-- 
Jing Xue

Re: git guidance

[Linus Torvalds]

On Thu, 29 Nov 2007, Jing Xue wrote:
> 
> By the way, the only SCM I have worked with that tries to mount its
> repository (or a view on top of it) as a file system is ClearCase with
> its dynamic views. And, between the buggy file system implementation,
> the intrusion on workflow, and the lack of scalability, at least in
> the organization I worked for, it turned out to be a horrible,
> horrible, horrible idea.

Doing a read-only mount setup tends to be pretty easy, but it's largely 
pointless except for specialty uses. Ie it's obviously not useful for 
actual *development*, but it can be useful for some other cases.

For example, a read-only revctrl filesystem can be a _very_ useful thing 
for test-farms, where you may have hundreds of clients that run tests on 
possibly different versions at the same time. In situations like that, the 
read-only mount can actually often be done as a user-space NFS server on 
some machine.

The advantage is that you don't need to export close to infinite amounts 
of versions from a "real" filesystem, or make the clients have their own 
copies. And if you do it as a user-space NFS server (or samba, for that 
matter), it's even portable, unlike many other approaches. The read-only 
part also makes 99% of all the complexity go away, and it turns out to be 
a fairly easy exercise to do.

So I don't think the filesystem approach is _wrong_ per se. But yes, doing 
it read-write is almost invariably a big mistake. On operatign systems 
that support a "union mount" approach, it's likely much better to have a 
read-only revctl thing, and then over-mount a regular filesystem on top of 
it.

Trying to make it read-write from the revctl engine standpoint is almost 
certainly totally insane.

				Linus

Re: git guidance

[Al Boldi]

Jing Xue wrote:
> Quoting Al Boldi <a1426z@gawab.com>:
> > Sure, browsing is the easy part, but Version Control starts when things
> > become writable.
>
> But how is that supposed to work?  What happens when you make some
> changes to a file and save it?  Do you want the "git file system" to
> commit it right aways or wait until you to issue a "commit" command?
> The first behavior would obviously be wrong, and the second would make
> the "file system" not operationally transparent anyways. Right?

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.

Linus Torvalds wrote:
> On Thu, 29 Nov 2007, Jing Xue wrote:
> > By the way, the only SCM I have worked with that tries to mount its
> > repository (or a view on top of it) as a file system is ClearCase with
> > its dynamic views. And, between the buggy file system implementation,
> > the intrusion on workflow, and the lack of scalability, at least in
> > the organization I worked for, it turned out to be a horrible,
> > horrible, horrible idea.

Judging an idea, based on a flawed implementation, doesn't prove that the 
idea itself is flawed.

And...
> Doing a read-only mount setup tends to be pretty easy, but it's largely
> pointless except for specialty uses. Ie it's obviously not useful for
> actual *development*, but it can be useful for some other cases.
>
> For example, a read-only revctrl filesystem can be a _very_ useful thing
> for test-farms, where you may have hundreds of clients that run tests on
> possibly different versions at the same time. In situations like that, the
> read-only mount can actually often be done as a user-space NFS server on
> some machine.
>
> The advantage is that you don't need to export close to infinite amounts
> of versions from a "real" filesystem, or make the clients have their own
> copies. And if you do it as a user-space NFS server (or samba, for that
> matter), it's even portable, unlike many other approaches. The read-only
> part also makes 99% of all the complexity go away, and it turns out to be
> a fairly easy exercise to do.
>
> So I don't think the filesystem approach is _wrong_ per se. But yes, doing
> it read-write is almost invariably a big mistake. On operatign systems
> that support a "union mount" approach, it's likely much better to have a
> read-only revctl thing, and then over-mount a regular filesystem on top of
> it.

You could probably do that, or you could instead use cp -al.  Both would 
require some hacks to allow some basic version control.

> Trying to make it read-write from the revctl engine standpoint is almost
> certainly totally insane.

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.

IOW, git currently only implements the server-side use-case, but fails to 
deliver on the client-side.  By introducing a git-client manager that 
handles the transparency needs of a single user, it should be possible to 
clearly isolate update semantics for both the client and the server, each 
handling their specific use-case.


Thanks!

--
Al

Re: git guidance

[Phillip Susi]

Al Boldi wrote:
> Judging an idea, based on a flawed implementation, doesn't prove that the 
> idea itself is flawed.

It isn't the implementation that is flawed, it is the idea.  The entire 
point of a change control system is that you explicitly define change 
sets and add comments to the set.  The filesystem was designed to allow 
changes to be made willy-nilly.  If your goal is to perform change 
control only with filesystem semantics, then you have a non starter as 
their goals are opposing.  Requiring an explicit command command is 
hardly burdensome, and otherwise, a git tree is perfectly transparent to 
non git aware tools.

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

It isn't missing a client manager, it was explicitly designed to not 
have one, at least not as a distinct entity from a server, because it 
does not use a client/server architecture.  This is very much by design, 
not a work around.

What transparency are you requiring here?  You can transparently read 
your git tree with all non git aware tools, what other meaning of 
transparency is there?

> IOW, git currently only implements the server-side use-case, but fails to 
> deliver on the client-side.  By introducing a git-client manager that 
> handles the transparency needs of a single user, it should be possible to 
> clearly isolate update semantics for both the client and the server, each 
> handling their specific use-case.

Any talk of client or server makes no sense since git does not use a 
client/server model.  If you wish to use a centralized repository, then 
git can be set up to transparently push/pull to/from said repository if 
you wish via hooks or cron jobs.

Re: git guidance

[Al Boldi]

Phillip Susi wrote:
> Al Boldi wrote:
> > IOW, git currently only implements the server-side use-case, but fails
> > to deliver on the client-side.  By introducing a git-client manager that
> > handles the transparency needs of a single user, it should be possible
> > to clearly isolate update semantics for both the client and the server,
> > each handling their specific use-case.
>
> Any talk of client or server makes no sense since git does not use a
> client/server model.

Whether git uses the client/server model or not does not matter; what matters 
is that there are two distinct use-cases at work here:  one on the 
server/repository, and the other on the client.  

> If you wish to use a centralized repository, then
> git can be set up to transparently push/pull to/from said repository if
> you wish via hooks or cron jobs.

Again, this only handles the interface to/from the server/repository, but 
once you pulled the sources, it leaves you without Version Control on the 
client.

By pulling the sources into a git-client manager mounted on some dir, it 
should be possible to let the developer work naturally/transparently in a 
readable/writeable manner, and only require his input when reverting locally 
or committing to the server/repository.


Thanks!

--
Al

Re: git guidance

[Andreas Ericsson]

Al Boldi wrote:
> Phillip Susi wrote:
>> Al Boldi wrote:
>>> IOW, git currently only implements the server-side use-case, but fails
>>> to deliver on the client-side.  By introducing a git-client manager that
>>> handles the transparency needs of a single user, it should be possible
>>> to clearly isolate update semantics for both the client and the server,
>>> each handling their specific use-case.
>> Any talk of client or server makes no sense since git does not use a
>> client/server model.
> 
> Whether git uses the client/server model or not does not matter; what matters 
> is that there are two distinct use-cases at work here:  one on the 
> server/repository, and the other on the client.  
> 

Git is distributed. The repository is everywhere. No server is actually needed.
Many use one anyway since it can be convenient. It's not, however, necessary.

>> If you wish to use a centralized repository, then
>> git can be set up to transparently push/pull to/from said repository if
>> you wish via hooks or cron jobs.
> 
> Again, this only handles the interface to/from the server/repository, but 
> once you pulled the sources, it leaves you without Version Control on the 
> client.
> 

No, that's CVS, SVN and other centralized scm's. With git you have perfect
version control on each peer. That's the entire idea behind "fully
distributed".

> By pulling the sources into a git-client manager mounted on some dir, it 
> should be possible to let the developer work naturally/transparently in a 
> readable/writeable manner, and only require his input when reverting locally 
> or committing to the server/repository.
> 

How is that different from what every SCM, including git, is doing today? The
user needs to tell the scm when it's time to take a snapshot of the current
state. Git is distributed though, so committing is usually not the same as
publishing. Is that lack of a single command to commit and publish what's
nagging you? If it's not, I completely fail to see what you're getting at,
unless you've only ever looked at repositories without a worktree attached,
or you think that git should work like an editor's "undo" functionality,
which would be quite insane.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git guidance

[Al Boldi]

Andreas Ericsson wrote:
> Al Boldi wrote:
> > Phillip Susi wrote:
> >> Al Boldi wrote:
> >>> IOW, git currently only implements the server-side use-case, but fails
> >>> to deliver on the client-side.  By introducing a git-client manager
> >>> that handles the transparency needs of a single user, it should be
> >>> possible to clearly isolate update semantics for both the client and
> >>> the server, each handling their specific use-case.
> >>
> >> Any talk of client or server makes no sense since git does not use a
> >> client/server model.
> >
> > Whether git uses the client/server model or not does not matter; what
> > matters is that there are two distinct use-cases at work here:  one on
> > the server/repository, and the other on the client.
>
> Git is distributed. The repository is everywhere. No server is actually
> needed. Many use one anyway since it can be convenient. It's not, however,
> necessary.

When you read server, don't read it as localized; a server can be 
distributed.  What distinguishes a server from an engine is that it has to 
handle a multi-user use-case.  How that is implemented, locally or remotely 
or distributed, is another issue.

> >> If you wish to use a centralized repository, then
> >> git can be set up to transparently push/pull to/from said repository if
> >> you wish via hooks or cron jobs.
> >
> > Again, this only handles the interface to/from the server/repository,
> > but once you pulled the sources, it leaves you without Version Control
> > on the client.
>
> No, that's CVS, SVN and other centralized scm's. With git you have perfect
> version control on each peer. That's the entire idea behind "fully
> distributed".

As explained before in this thread, replicating the git tree on the client 
still doesn't provide the required transparency.

> > By pulling the sources into a git-client manager mounted on some dir, it
> > should be possible to let the developer work naturally/transparently in
> > a readable/writeable manner, and only require his input when reverting
> > locally or committing to the server/repository.
>
> How is that different from what every SCM, including git, is doing today?
> The user needs to tell the scm when it's time to take a snapshot of the
> current state. Git is distributed though, so committing is usually not the
> same as publishing. Is that lack of a single command to commit and publish
> what's nagging you? If it's not, I completely fail to see what you're
> getting at, unless you've only ever looked at repositories without a
> worktree attached, or you think that git should work like an editor's
> "undo" functionality, which would be quite insane.

You need to re-read the thread.


Thanks!

--
Al

Re: git guidance

[Johannes Schindelin]

Hi,

On Fri, 7 Dec 2007, Al Boldi wrote:

> Andreas Ericsson wrote:
> > Al Boldi wrote:
> >
> > > By pulling the sources into a git-client manager mounted on some 
> > > dir, it should be possible to let the developer work 
> > > naturally/transparently in a readable/writeable manner, and only 
> > > require his input when reverting locally or committing to the 
> > > server/repository.
> >
> > How is that different from what every SCM, including git, is doing 
> > today? The user needs to tell the scm when it's time to take a 
> > snapshot of the current state. Git is distributed though, so 
> > committing is usually not the same as publishing. Is that lack of a 
> > single command to commit and publish what's nagging you? If it's not, 
> > I completely fail to see what you're getting at, unless you've only 
> > ever looked at repositories without a worktree attached, or you think 
> > that git should work like an editor's "undo" functionality, which 
> > would be quite insane.
> 
> You need to re-read the thread.

I don't know why you write that, and then say thanks.  Clearly, what you 
wrote originally, and what Andreas pointed out, were quite obvious 
indicators that git already does what you suggest.

You _do_ work "transparently" (whatever you understand by that overused 
term) in the working directory, unimpeded by git.

And whenever it is time to revert or commit, you cry for help, invoking 
git.

So either you succeeded in making yourself misunderstood, or Andreas had 
quite the obvious and correct comment for you.

Not that diffcult,
Dscho

Re: git guidance

[Al Boldi]

Johannes Schindelin wrote:
> Hi,

Hi

> On Fri, 7 Dec 2007, Al Boldi wrote:
> > You need to re-read the thread.
>
> I don't know why you write that, and then say thanks.  Clearly, what you
> wrote originally, and what Andreas pointed out, were quite obvious
> indicators that git already does what you suggest.
>
> You _do_ work "transparently" (whatever you understand by that overused
> term) in the working directory, unimpeded by git.

If you go back in the thread, you may find a link to a gitfs client that 
somebody kindly posted.  This client pretty much defines the transparency 
I'm talking about.  The only problem is that it's read-only.

To make it really useful, it has to support versioning locally, disconnected 
from the server repository.  One way to implement this, could be by 
committing every update unconditionally to an on-the-fly created git 
repository private to the gitfs client.

With this transparently created private scratch repository it should then be 
possible for the same gitfs to re-expose the locally created commits, all 
without any direct user-intervention.

Later, this same scratch repository could then be managed by the normal 
git-management tools/commands to ultimately update the backend git 
repositories.

BTW:  Sorry for my previous posts that contained the wrong date; it seems 
that hibernation sometimes advances the date by a full 24h.  Has anybody 
noticed this as well?


Thanks!

--
Al

Re: git guidance

[Andreas Ericsson]

Al Boldi wrote:
> Johannes Schindelin wrote:
>> Hi,
> 
> Hi
> 
>> On Fri, 7 Dec 2007, Al Boldi wrote:
>>> You need to re-read the thread.
>> I don't know why you write that, and then say thanks.  Clearly, what you
>> wrote originally, and what Andreas pointed out, were quite obvious
>> indicators that git already does what you suggest.
>>
>> You _do_ work "transparently" (whatever you understand by that overused
>> term) in the working directory, unimpeded by git.
> 
> If you go back in the thread, you may find a link to a gitfs client that 
> somebody kindly posted.  This client pretty much defines the transparency 
> I'm talking about.  The only problem is that it's read-only.
> 
> To make it really useful, it has to support versioning locally, disconnected 
> from the server repository.  One way to implement this, could be by 
> committing every update unconditionally to an on-the-fly created git 
> repository private to the gitfs client.
> 

Earlier you said that you need to be able to tell git when you want to make
a commit, which means pretty much any old filesystem could serve as gitfs.
Now you're saying you want every single update to be committed, which would
make it mimic an editor's undo functionality. I still don't get what it is
you really want.

> With this transparently created private scratch repository it should then be 
> possible for the same gitfs to re-expose the locally created commits, all 
> without any direct user-intervention.
> 
> Later, this same scratch repository could then be managed by the normal 
> git-management tools/commands to ultimately update the backend git 
> repositories.
> 

That's exactly what's happening today. I imagine whoever wrote the gitfs
thing did so to facilitate testing, or as some form of intellectual
masturbation.


So, to get to the bottom of this, which of the following workflows is it you
want git to support?

### WORKFLOW A ###
edit, edit, edit
edit, edit, edit
edit, edit, edit
Oops I made a mistake and need to hop back to "current - 12".
edit, edit, edit
edit, edit, edit
publish everything, similar to just tarring up your workdir and sending out
### END WORKFLOW A ###

### WORKFLOW B ###
edit, edit, edit
ok this looks good, I want to save a checkpoint here
edit, edit, edit
looks good again. next checkpoint
edit, edit, edit
oh crap, back to checkpoint 2
edit, edit, edit
ooh, that's better. save a checkpoint and publish those checkpoints
### END WORKFLOW B ###

If you could just answer that question and stop writing "transparent" or
any synonym thereof six times in each email, we can possibly help you.

As it stands now though, nobody is very interested because you haven't
explained how you want this "transparency" of yours to work in an every
day scenario.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git guidance

[Al Boldi]

Andreas Ericsson wrote:
> So, to get to the bottom of this, which of the following workflows is it
> you want git to support?
>
> ### WORKFLOW A ###
> edit, edit, edit
> edit, edit, edit
> edit, edit, edit
> Oops I made a mistake and need to hop back to "current - 12".
> edit, edit, edit
> edit, edit, edit
> publish everything, similar to just tarring up your workdir and sending
> out ### END WORKFLOW A ###
>
> ### WORKFLOW B ###
> edit, edit, edit
> ok this looks good, I want to save a checkpoint here
> edit, edit, edit
> looks good again. next checkpoint
> edit, edit, edit
> oh crap, back to checkpoint 2
> edit, edit, edit
> ooh, that's better. save a checkpoint and publish those checkpoints
> ### END WORKFLOW B ###

### WORKFLOW C ###
for every save on a gitfs mounted dir, do an implied checkpoint, commit, or 
publish (should be adjustable), on its privately created on-the-fly 
repository.
### END WORKFLOW C ###

For example:

  echo "// last comment on this file" >> /gitfs.mounted/file

should do an implied checkpoint, and make these checkpoints immediately 
visible under some checkpoint branch of the gitfs mounted dir.

Note, this way the developer gets version control without even noticing, and 
works completely transparent to any kind of application.


Thanks!

--
Al

Re: git guidance

[Jakub Narebski]

Al Boldi <a1426z@gawab.com> writes:
> Andreas Ericsson wrote:

>> So, to get to the bottom of this, which of the following workflows is it
>> you want git to support?
>>
>> ### WORKFLOW A ###
>> edit, edit, edit
>> edit, edit, edit
>> edit, edit, edit
>> Oops I made a mistake and need to hop back to "current - 12".
>> edit, edit, edit
>> edit, edit, edit
>> publish everything, similar to just tarring up your workdir and sending
>> out ### END WORKFLOW A ###
>>
>> ### WORKFLOW B ###
>> edit, edit, edit
>> ok this looks good, I want to save a checkpoint here
>> edit, edit, edit
>> looks good again. next checkpoint
>> edit, edit, edit
>> oh crap, back to checkpoint 2
>> edit, edit, edit
>> ooh, that's better. save a checkpoint and publish those checkpoints
>> ### END WORKFLOW B ###
> 
> ### WORKFLOW C ###
> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or 
> publish (should be adjustable), on its privately created on-the-fly 
> repository.
> ### END WORKFLOW C ###

It looks like it is WORKFLOW A (with the fact that each ',' is file
save stated explicitely rather than implicitely).
 
> For example:
> 
>   echo "// last comment on this file" >> /gitfs.mounted/file
> 
> should do an implied checkpoint, and make these checkpoints immediately 
> visible under some checkpoint branch of the gitfs mounted dir.
> 
> Note, this way the developer gets version control without even noticing, and 
> works completely transparent to any kind of application.

Why not use versioning filesystem for that, for example ext3cow
(which looks suprisingly git-like, when you take into account that
for ext3cow history is linear and centralized, so one can use date
or sequential number to name commits).

See GitLinks page on Git Wiki, "Other links" section:
  http://www.ext3cow.com/

Version control system is all about WORKFLOW B, where programmer
controls when it is time to commit (and in private repository he/she
can then rewrite history to arrive at "Perfect patch series"[*1*]);
something that for example CVS failed at, requiring programmer to do
a merge if upstream has any changes when trying to commit.

[*1*] I have lost link to post at LKML about rewriting history to
      arrive at perfect patch _series_. IIRC I have found it first
      time on this mailing list. I would be grateful for sending this
      link if you have it. TIA.

-- 
Jakub Narebski
ShadeHawk on #git

Re: git guidance

[Al Boldi]

Jakub Narebski wrote:
> Al Boldi <a1426z@gawab.com> writes:
> > For example:
> >
> >   echo "// last comment on this file" >> /gitfs.mounted/file
> >
> > should do an implied checkpoint, and make these checkpoints immediately
> > visible under some checkpoint branch of the gitfs mounted dir.
> >
> > Note, this way the developer gets version control without even noticing,
> > and works completely transparent to any kind of application.
>
> Why not use versioning filesystem for that, for example ext3cow
> (which looks suprisingly git-like, when you take into account that
> for ext3cow history is linear and centralized, so one can use date
> or sequential number to name commits).
>
> See GitLinks page on Git Wiki, "Other links" section:
>   http://www.ext3cow.com/

Sure, Linus mentioned the cow idea before in this thread, but you would still 
need a few hacks to get some basic Version Control features.  

> Version control system is all about WORKFLOW B, where programmer
> controls when it is time to commit (and in private repository he/she
> can then rewrite history to arrive at "Perfect patch series"[*1*]);
> something that for example CVS failed at, requiring programmer to do
> a merge if upstream has any changes when trying to commit.

Because WORKFLOW C is transparent, it won't affect other workflows.  So you 
could still use your normal WORKFLOW B in addition to WORKFLOW C, gaining an 
additional level of version control detail at no extra cost other than the 
git-engine scratch repository overhead.

BTW, is git efficient enough to handle WORKFLOW C?


Thanks!

--
Al

Re: git guidance

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:

> Because WORKFLOW C is transparent, it won't affect other workflows.  So you 
> could still use your normal WORKFLOW B in addition to WORKFLOW C, gaining an 
> additional level of version control detail at no extra cost other than the 
> git-engine scratch repository overhead.
> 
> BTW, is git efficient enough to handle WORKFLOW C?

Imagine the number of commits a 'make clean; make' will do in a kernel tree, as
it commits all those .o files... :)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: git guidance

[Luke Lu]

On Dec 7, 2007, at 11:36 AM, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
>
>> Because WORKFLOW C is transparent, it won't affect other  
>> workflows.  So you
>> could still use your normal WORKFLOW B in addition to WORKFLOW C,  
>> gaining an
>> additional level of version control detail at no extra cost other  
>> than the
>> git-engine scratch repository overhead.
>>
>> BTW, is git efficient enough to handle WORKFLOW C?
>
> Imagine the number of commits a 'make clean; make' will do in a  
> kernel tree, as
> it commits all those .o files... :)

My guess is that Al is not really a developer (product management/ 
marketing?), what he has in mind is probably not an SCM but a backup  
system a la Mac's time machine or Netapp's snapshots that also  
support disconnected commits. I think that git could be a suitable  
engine for such systems, after a few tweaks to avoid compressing  
already compressed blobs like jpeg, mp3 and mpeg etc.

__Luke

Re: git guidance

[Al Boldi]

Valdis.Kletnieks@vt.edu wrote:
> On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
> > Because WORKFLOW C is transparent, it won't affect other workflows.  So
> > you could still use your normal WORKFLOW B in addition to WORKFLOW C,
> > gaining an additional level of version control detail at no extra cost
> > other than the git-engine scratch repository overhead.
> >
> > BTW, is git efficient enough to handle WORKFLOW C?
>
> Imagine the number of commits a 'make clean; make' will do in a kernel
> tree, as it commits all those .o files... :)

.o files???

It probably goes without saying, that gitfs should have some basic 
configuration file to setup its transparent behaviour, and which would most 
probably contain an include / exclude file-filter mask, and probably other 
basic configuration options.  But this is really secondary to the 
implementation, and the question remains whether git is efficient enough.

IOW, how big is the git commit overhead as compared to a normal copy?


Thanks!

--
Al

Re: git guidance

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:

> It probably goes without saying, that gitfs should have some basic 
> configuration file to setup its transparent behaviour

But then it's not *truly* transparent, is it?

And that leaves another question - if you make a config file that excludes
all the .o files - then what's backing the .o files?  Those data blocks need
to be *someplace*.  Maybe you can do something ugly like use unionfs to
combine your gitfs with something else to store the other files...

But at that point, you're probably better off just creating a properly
designed versioning filesystem.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: git guidance

[Al Boldi]

Valdis.Kletnieks@vt.edu wrote:
> On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:
> > It probably goes without saying, that gitfs should have some basic
> > configuration file to setup its transparent behaviour
>
> But then it's not *truly* transparent, is it?

Don't mistake transparency with some form of auto-heuristic.  Transparency 
only means that it inserts functionality without impeding your normal 
workflow.

> And that leaves another question - if you make a config file that excludes
> all the .o files - then what's backing the .o files?  Those data blocks
> need to be *someplace*.  Maybe you can do something ugly like use unionfs
> to combine your gitfs with something else to store the other files...

Or any number of other possible implementation scenarios...

> But at that point, you're probably better off just creating a properly
> designed versioning filesystem.

But gitfs is not about designing a versioning filesystem, it's about 
designing a transparent interface into git to handle an SCM use-case.


Thanks!

--
Al

Re: git guidance

[Johannes Schindelin]

Hi,

On Fri, 7 Dec 2007, Al Boldi wrote:

> Jakub Narebski wrote:
>
> > Version control system is all about WORKFLOW B, where programmer 
> > controls when it is time to commit (and in private repository he/she 
> > can then rewrite history to arrive at "Perfect patch series"[*1*]); 
> > something that for example CVS failed at, requiring programmer to do a 
> > merge if upstream has any changes when trying to commit.
> 
> Because WORKFLOW C is transparent, it won't affect other workflows.  So 
> you could still use your normal WORKFLOW B in addition to WORKFLOW C, 
> gaining an additional level of version control detail at no extra cost 
> other than the git-engine scratch repository overhead.
> 
> BTW, is git efficient enough to handle WORKFLOW C?

The question is not if git is efficient enough to handle workflow C, but 
if that worflow is efficient enough to help anybody.

Guess what takes me the longest time when committing?  The commit message.  
But it is really helpful, so there is a _point_ in writing one, and there 
is a _point_ in committing when I do it: it is a point in time where I 
expect the tree to be in a good shape, to be compilable, and to solve a 
specific problem which I describe in the commit message.

So I absolutely hate this "transparency".  Git _is_ transparent; it does 
not affect any of my other tools; they still work very well 
thankyouverymuch.

What your version of "transparency" would do: destroy bisectability, make 
an absolute gibberish of the history, and more!

Nobody could read the output of "git log" and form an understanding what 
was done.  Nobody could read the commit message for a certain "git blame"d 
line that she tries to make sense of.

IOW you would revert the whole meaning of the term Source Code Management.

Hth,
Dscho

Re: git guidance

[Andreas Ericsson]

Al Boldi wrote:
> Andreas Ericsson wrote:
>> So, to get to the bottom of this, which of the following workflows is it
>> you want git to support?
>>
>> ### WORKFLOW A ###
>> edit, edit, edit
>> edit, edit, edit
>> edit, edit, edit
>> Oops I made a mistake and need to hop back to "current - 12".
>> edit, edit, edit
>> edit, edit, edit
>> publish everything, similar to just tarring up your workdir and sending
>> out ### END WORKFLOW A ###
>>
>> ### WORKFLOW B ###
>> edit, edit, edit
>> ok this looks good, I want to save a checkpoint here
>> edit, edit, edit
>> looks good again. next checkpoint
>> edit, edit, edit
>> oh crap, back to checkpoint 2
>> edit, edit, edit
>> ooh, that's better. save a checkpoint and publish those checkpoints
>> ### END WORKFLOW B ###
> 
> ### WORKFLOW C ###
> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or 
> publish (should be adjustable), on its privately created on-the-fly 
> repository.
> ### END WORKFLOW C ###
> 

So you *do* want an editor's undo function, but for an entire filesystem.
That's a handy thing to have every now and then, but it's not what git
(or any other scm) does.

> For example:
> 
>   echo "// last comment on this file" >> /gitfs.mounted/file
> 
> should do an implied checkpoint, and make these checkpoints immediately 
> visible under some checkpoint branch of the gitfs mounted dir.
> 
> Note, this way the developer gets version control without even noticing, and 
> works completely transparent to any kind of application.
> 

One other thing that's fairly important to note is that this can never
ever handle changesets, since each write() of each file will be a commit
on its own. It's so far from what git does that I think you'd be better
off just implementing it from scratch, or looking at a versioned fs, like
Jakub suggested in his reply.

You're also neglecting one very important aspect of what an SCM provides
if you go down this road, namely project history. You basically have two
choices with this "implicit save on each edit":
* force the user to supply a commit message for each and every edit
* ignore commit messages altogether

Obviously, forcing a commit message each time is the only way to get some
sort of proper history to look at after it's done, but it's also such an
appalling nuisance that I doubt *anyone* will actually like that, and since
changesets aren't supported, you'll have "implement xniz api, commit 1 of X"
messages. Cumbersome, stupid, and not very useful.

Ignoring commit messages altogether means you ignore the entire history,
and the SCM then becomes a filesystem-wide "undo" cache. This could
ofcourse work, but it's something akin to building a nuclear powerplant
to power a single lightbulb.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git guidance

[david]

On Fri, 7 Dec 2007, Al Boldi wrote:

> Andreas Ericsson wrote:
>> So, to get to the bottom of this, which of the following workflows is it
>> you want git to support?
>>
>> ### WORKFLOW A ###
>> edit, edit, edit
>> edit, edit, edit
>> edit, edit, edit
>> Oops I made a mistake and need to hop back to "current - 12".
>> edit, edit, edit
>> edit, edit, edit
>> publish everything, similar to just tarring up your workdir and sending
>> out ### END WORKFLOW A ###
>>
>> ### WORKFLOW B ###
>> edit, edit, edit
>> ok this looks good, I want to save a checkpoint here
>> edit, edit, edit
>> looks good again. next checkpoint
>> edit, edit, edit
>> oh crap, back to checkpoint 2
>> edit, edit, edit
>> ooh, that's better. save a checkpoint and publish those checkpoints
>> ### END WORKFLOW B ###
>
> ### WORKFLOW C ###
> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or
> publish (should be adjustable), on its privately created on-the-fly
> repository.
> ### END WORKFLOW C ###
>
> For example:
>
>  echo "// last comment on this file" >> /gitfs.mounted/file
>
> should do an implied checkpoint, and make these checkpoints immediately
> visible under some checkpoint branch of the gitfs mounted dir.
>
> Note, this way the developer gets version control without even noticing, and
> works completely transparent to any kind of application.

so if you have a script that does

echo "mail header" >tmpfile
echo "subject: >>tmpfile
echo >>tmpfile
echo "body" >>tmpfile

you want to have four seperate commits

what if you have a perl script

open outfile ">tmpfile";
print outfile "mail header\n";
print outfile "subject:\n\n";
print outfile "body\n";
close ourfile;

how many seperate commits do you think should take place?

what if $|=1 (unbuffered output, so that each print statement becomes 
visable to other programs immediatly)?

what if the file is changed via mmap? should each byte/word written to 
memory be a commit? or when the mmap is closed? or when the kernel happens 
to flush the page to disk?

'recording every change to a filesystem' is a very incomplete definition 
of a goal.

David Lang

Re: git guidance

[Björn Steinbrink]

[-- Attachment #1: Type: text/plain, Size: 3930 bytes --]

On 2007.12.07 13:53:11 +0300, Al Boldi wrote:
> Andreas Ericsson wrote:
> > So, to get to the bottom of this, which of the following workflows is it
> > you want git to support?
> >
> > ### WORKFLOW A ###
> > edit, edit, edit
> > edit, edit, edit
> > edit, edit, edit
> > Oops I made a mistake and need to hop back to "current - 12".
> > edit, edit, edit
> > edit, edit, edit
> > publish everything, similar to just tarring up your workdir and sending
> > out ### END WORKFLOW A ###
> >
> > ### WORKFLOW B ###
> > edit, edit, edit
> > ok this looks good, I want to save a checkpoint here
> > edit, edit, edit
> > looks good again. next checkpoint
> > edit, edit, edit
> > oh crap, back to checkpoint 2
> > edit, edit, edit
> > ooh, that's better. save a checkpoint and publish those checkpoints
> > ### END WORKFLOW B ###
> 
> ### WORKFLOW C ###
> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or 
> publish (should be adjustable), on its privately created on-the-fly 
> repository.
> ### END WORKFLOW C ###
> 
> For example:
> 
>   echo "// last comment on this file" >> /gitfs.mounted/file
> 
> should do an implied checkpoint, and make these checkpoints immediately 
> visible under some checkpoint branch of the gitfs mounted dir.
> 
> Note, this way the developer gets version control without even noticing, and 
> works completely transparent to any kind of application.

Ouch... That looks worse than "plain" per-file versioning. Not only do
you per definition get "broken" commits if there's a change that affects
two dependent files, you also get an insane amount of commits just for
testing stuff, or fixing bugs.

And unless you use some kind of union-fs on top (or keep ignored files
in special unversioned area in your gitfs, which seems somewhat ugly),
you'll probably also have to track lots of files in the working
directory that are generated, unless you want to re-generate them after
each reboot. And that leads to even more absolutely useless revisions.

Just thinking of my vim .swp files (which I definitely don't want to
loose on a crash/power outtage/pkill -9 .<ENTER> dammit) makes me scream
because of the gazillion of commits they will produce (and no, I don't
want them in some special out of tree directory).

Plus, I have vim setup to _replace_ files on write, so that I can more
easily use hard-linked copies with changing all copies at once _unless_
I explicitly want to, meaning that I'd get full remove/add commits,
which are absolutely useless. And trying to detect such patterns
(rename, then write the changed file with the old name and then delete
the renamed file) is probably not worth the trouble, because you
coincidently might _want_ to have just these three steps recorded when
you happen to perform them manually. And if you go for heuristics,
you'll complain each time you get a false-positive/negative.


That said, out of pure curiousness I came up with the attached script
which just uses inotifywait to watch a directory and issue git commands
on certain events. It is extremely stupid, but seems to work. And at
least it hasn't got the drawbacks of a real gitfs regarding the need to
have a "separate" non-versioned storage area for the working directory,
because it simply uses the existing working directory wherever that
might be stored. It doesn't use GIT_DIR/WORK_DIR yet, but hey, should be
easy to add...

Feel free to mess with that thing, hey, maybe you even like it and
extend it to match your proposed workflow even more. I for sure won't
use or even extend it, so you're likely on your own there.

Side-note: Writing that script probably took less time than writing this
email and probably less time than was wasted on this topic. Makes me
want to use today's preferred "Code talks, b...s... walks" statement,
but I'll refrain from that... Just because I lack the credibility to say
that, and the script attached is quite crappy ;-)

Björn

[-- Attachment #2: git-watch --]
[-- Type: text/plain, Size: 814 bytes --]

#!/bin/bash
inotifywait -m -r --exclude ^\./\.git/.* -e close_write -e move -e create -e delete . 2>/dev/null |
while read FILE_PATH EVENT FILE_NAME
do
	FILE_NAME="$FILE_PATH$FILE_NAME"
	FILE_NAME=${FILE_NAME#./}

	# git doesn't care about directories
	if [ -d "$FILE_NAME" ]
	then
		continue
	fi

	case "$EVENT" in
		*CLOSE_WRITE*)
		ACTION=change
		;;
		*MOVED_TO*)
		ACTION=create
		;;
		*MODIFY*)
		ACTION=change
		;;
		*DELETE*)
		ACTION=delete
		;;
		*MOVED_FROM*)
		ACTION=delete
		;;
		*CREATE*)
		ACTION=create
		;;
		*)
		continue
		;;
	esac

	case $ACTION in
		create)
		git add "$FILE_NAME"
		git commit -m "$FILE_NAME created"
		;;
		delete)
		git rm --cached "$FILE_NAME"
		git commit -m "$FILE_NAME removed"
		;;
		change)
		git add "$FILE_NAME"
		git commit -m "$FILE_NAME changed"
		;;
	esac
done

inotify-commit, was Re: git guidance

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2440 bytes --]

Hi,

[long Cc: list culled, as they probably forgot about this thread]

On Fri, 7 Dec 2007, Björn Steinbrink wrote:

> That said, out of pure curiousness I came up with the attached script 
> which just uses inotifywait to watch a directory and issue git commands 
> on certain events. It is extremely stupid, but seems to work. And at 
> least it hasn't got the drawbacks of a real gitfs regarding the need to 
> have a "separate" non-versioned storage area for the working directory, 
> because it simply uses the existing working directory wherever that 
> might be stored. It doesn't use GIT_DIR/WORK_DIR yet, but hey, should be 
> easy to add...
> 
> Feel free to mess with that thing, hey, maybe you even like it and
> extend it to match your proposed workflow even more. I for sure won't
> use or even extend it, so you're likely on your own there.
> 
> Side-note: Writing that script probably took less time than writing this
> email and probably less time than was wasted on this topic. Makes me
> want to use today's preferred "Code talks, b...s... walks" statement,
> but I'll refrain from that... Just because I lack the credibility to say
> that, and the script attached is quite crappy ;-)

I could not agree more with the statement.

As it happens, I have a very delicate setup that we tested in a test 
environment as much as possible, but now we have to deploy it and I want 
to be able to rewind very quickly to a known-good state.

So I adjusted your script a little.  It now reads like this:

-- snip --
#!/bin/sh

# Originally by Bjoern Steinbrink, simplified by Johannes Schindelin

inotifywait -m -r --exclude ^\./\.git/.* \
        -e close_write -e move -e create -e delete . 2>/dev/null |
while read FILE_PATH EVENT FILE_NAME
do
        FILE_NAME="$FILE_PATH$FILE_NAME"
        FILE_NAME=${FILE_NAME#./}

        # git doesn't care about directories
        test -d "$FILE_NAME" && continue

        case "$EVENT" in
        *MOVED_TO*|*CREATE*)
                git add "$FILE_NAME"
                git commit -m "$FILE_NAME created"
                ;;
        *CLOSE_WRITE*|*MODIFY*)
                git add "$FILE_NAME"
                git commit -m "$FILE_NAME changed"
                ;;
        *DELETE*|*MOVED_FROM*)
                git rm --cached "$FILE_NAME"
                git commit -m "$FILE_NAME removed"
                ;;
        esac
done
-- snap --

Thanks for your original script!

Ciao,
Dscho

Re: git guidance

[Phillip Susi]

Al Boldi wrote:
> When you read server, don't read it as localized; a server can be 
> distributed.  What distinguishes a server from an engine is that it has to 
> handle a multi-user use-case.  How that is implemented, locally or remotely 
> or distributed, is another issue.

And again, git handles both use cases, so what's your point?

> As explained before in this thread, replicating the git tree on the client 
> still doesn't provide the required transparency.

It has been pointed out to you that it DOES.  Either that or nobody else 
understands your nebulous use of "transparency" so maybe you should 
define it like we've been asking you.  Furthermore, the comment you 
replied to said nothing about transparency, nor did your comment it was 
in reply to; rather it was pointing out the fact that your statement 
that the git can not perform version control on the client is patently 
false.

>> How is that different from what every SCM, including git, is doing today?
>> The user needs to tell the scm when it's time to take a snapshot of the
>> current state. Git is distributed though, so committing is usually not the
>> same as publishing. Is that lack of a single command to commit and publish
>> what's nagging you? If it's not, I completely fail to see what you're
>> getting at, unless you've only ever looked at repositories without a
>> worktree attached, or you think that git should work like an editor's
>> "undo" functionality, which would be quite insane.
> 
> You need to re-read the thread.

Perhaps you should.  We have been trying to get you to explain how you 
think git isn't "transparent" while at the same time pointing out how we 
think it is.  You have failed to demonstrate any evidence to back up 
your claims, all of which have been shown to be false.

Re: git guidance

[Martin Langhoff]

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

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


m

Re: git guidance

[Al Boldi]

Willy Tarreau wrote:
> It should not turn into an endless thread led by people who want to
> redefine GIT's roadmap, but experience sharing helps a lot with GIT.

Well, now that you mentioned it, if there is one thing I dislike, it's for 
version control to start mutilating your sources.  Version Control should be 
completely transparent.  GIT isn't.


Thanks!

--
Al

Re: git guidance

[Rogan Dawes]

Al Boldi wrote:
> Willy Tarreau wrote:
>> It should not turn into an endless thread led by people who want to
>> redefine GIT's roadmap, but experience sharing helps a lot with GIT.
> 
> Well, now that you mentioned it, if there is one thing I dislike, it's for 
> version control to start mutilating your sources.  Version Control should be 
> completely transparent.  GIT isn't.
> 
> Thanks!
> 
> --
> Al
> 

Care to explain? Git is quite happy handling arbitrary binary content, 
so I find it difficult to believe that it is changing your source code 
in strange ways.

Rogan

Re: git guidance

[Johannes Schindelin]

Hi,

On Wed, 28 Nov 2007, Rogan Dawes wrote:

> Al Boldi wrote:
>
> > Willy Tarreau wrote:
> >
> > > It should not turn into an endless thread led by people who want to 
> > > redefine GIT's roadmap, but experience sharing helps a lot with GIT.
> > 
> > Well, now that you mentioned it, if there is one thing I dislike, it's 
> > for version control to start mutilating your sources.  Version Control 
> > should be completely transparent.  GIT isn't.
> 
> Care to explain? Git is quite happy handling arbitrary binary content, 
> so I find it difficult to believe that it is changing your source code 
> in strange ways.

It is nice of you to ask him to explain: Unless this handwaving claim is 
substantiated, it is quite hard to argue with.

Ciao,
Dscho

Re: git guidance

[Al Boldi]

Johannes Schindelin wrote:
> Hi,

Hi!

git@vger sometimes bounces, so let's leave lkml as backup.

> On Wed, 28 Nov 2007, Rogan Dawes wrote:
> > Al Boldi wrote:
> > > Willy Tarreau wrote:
> > > > It should not turn into an endless thread led by people who want to
> > > > redefine GIT's roadmap, but experience sharing helps a lot with GIT.
> > >
> > > Well, now that you mentioned it, if there is one thing I dislike, it's
> > > for version control to start mutilating your sources.  Version Control
> > > should be completely transparent.  GIT isn't.
> >
> > Care to explain? Git is quite happy handling arbitrary binary content,
> > so I find it difficult to believe that it is changing your source code
> > in strange ways.
>
> It is nice of you to ask him to explain: Unless this handwaving claim is
> substantiated, it is quite hard to argue with.

Sure, the problem with GIT is that it stores the sources inside a backend 
container that is only accessible via GIT; iow, you can't retrieve your 
sources directly / transparently.

One way to achieve transparency could be to allow mounting GIT on a dir-mount 
point.  And just use that dir normally, while GIT manages all the rest in 
the background.


Thanks!

--
Al

Re: git guidance

[Johannes Schindelin]

Hi,

On Wed, 28 Nov 2007, Al Boldi wrote:

> git@vger sometimes bounces, so let's leave lkml as backup.

Fair enough.

> Johannes Schindelin wrote:
> > On Wed, 28 Nov 2007, Rogan Dawes wrote:
> > > Al Boldi wrote:
> > > > Willy Tarreau wrote:
> > > > > It should not turn into an endless thread led by people who want 
> > > > > to redefine GIT's roadmap, but experience sharing helps a lot 
> > > > > with GIT.
> > > >
> > > > Well, now that you mentioned it, if there is one thing I dislike, 
> > > > it's for version control to start mutilating your sources.  
> > > > Version Control should be completely transparent.  GIT isn't.
> > >
> > > Care to explain? Git is quite happy handling arbitrary binary 
> > > content, so I find it difficult to believe that it is changing your 
> > > source code in strange ways.
> >
> > It is nice of you to ask him to explain: Unless this handwaving claim 
> > is substantiated, it is quite hard to argue with.
> 
> Sure, the problem with GIT is that it stores the sources inside a 
> backend container that is only accessible via GIT; iow, you can't 
> retrieve your sources directly / transparently.

That is a very funny way to define a "transparent SCM".  Are you 
complaining about SQL servers being "not transparent"?

By that definition, no SCM, not even CVS, is transparent.  Nothing short 
of unpacked directories of all versions (wasting a lot of disk space) 
would.

IOW the issue you raised is a non-issue.

Ciao,
Dscho

Re: git guidance

[Al Boldi]

Johannes Schindelin wrote:
> By that definition, no SCM, not even CVS, is transparent.  Nothing short
> of unpacked directories of all versions (wasting a lot of disk space)
> would.

Who said anything about unpacking?

I'm talking about GIT transparently serving a Virtual Version Control dir to 
be mounted on the client.


Thanks!

--
Al

Re: git guidance

[Jakub Narebski]

Al Boldi wrote:
> Johannes Schindelin wrote:

>> By that definition, no SCM, not even CVS, is transparent.  Nothing short
>> of unpacked directories of all versions (wasting a lot of disk space)
>> would.
> 
> Who said anything about unpacking?
> 
> I'm talking about GIT transparently serving a Virtual Version Control dir to 
> be mounted on the client.

Are you talking about something like (in alpha IIRC) gitfs?

  http://www.sfgoth.com/~mitch/linux/gitfs/


Besides, you can always use "git show <revision>:<file>". For example
gitweb (and I think other web interfaces) can show any version of a file
or a directory, accessing only repository.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git guidance

[Al Boldi]

Jakub Narebski wrote:
> Al Boldi wrote:
> > Johannes Schindelin wrote:
> >> By that definition, no SCM, not even CVS, is transparent.  Nothing
> >> short of unpacked directories of all versions (wasting a lot of disk
> >> space) would.
> >
> > Who said anything about unpacking?
> >
> > I'm talking about GIT transparently serving a Virtual Version Control
> > dir to be mounted on the client.
>
> Are you talking about something like (in alpha IIRC) gitfs?
>
>   http://www.sfgoth.com/~mitch/linux/gitfs/

This looks like a good start.

> Besides, you can always use "git show <revision>:<file>". For example
> gitweb (and I think other web interfaces) can show any version of a file
> or a directory, accessing only repository.

Sure, browsing is the easy part, but Version Control starts when things 
become writable.


Thanks for the link!

--
Al

Re: git guidance

[Kyle Moffett]

On Nov 29, 2007, at 00:27:04, Al Boldi wrote:
> Jakub Narebski wrote:
>> Besides, you can always use "git show <revision>:<file>". For  
>> example gitweb (and I think other web interfaces) can show any  
>> version of a file or a directory, accessing only repository.
>
> Sure, browsing is the easy part, but Version Control starts when  
> things become writable.

But... git history is very inherently completely immutable once  
created... that's the only way you can index everything with a simple  
SHA-1.  If you want to write to the "git filesystem" by adding new  
commits then you need to use the appropriate commands, same as every  
other VCS on the planet.

Cheers,
Kyle Moffett