GitFS: Report #4

[Manzur]

Hi All!

First of all, I want to thank you all for participating in discussion.

So, last week besides doing what was planned(completing file server
interface with existing library functions), I forked the project, and
created read-only version of gitfs with following layout:

$ mount {myfs repo} mntpt

$ cd mntpt
$ ls
d­rwxr­xr­x M 4 manzur manzur 314 Jun 25 20:22 master
d­rwxr­xr­x M 4 manzur manzur 314 Jun 25 20:22 rdonly­gitfs

Each of the above entry is a branch, and each of them contains
following files:

tree - snapshot of the file tree when commit was executed. You can
browse it and read files from it.
parent1 - first parent of commit
...
parentN - Nth parent of commit
commit_msg - commit message
log - log beginning from this commit(at the moment, it's more like old
rev-tree than like git log)

As you can see, it lacks repository manipulation mechanisms. To add
such features I decided to classify git commands. Basic git commands
like git add, rm, cat-file, show will be expressed via cd, ls, cat,
cp, mv and rm.
Other complicated commands will be executed through ctl file, or by
writing to the file itself, if it's a file-specific command.
Each file under some branch will have two modes: command and textual.
Modes are changed by chgrping to the special value. By default, it's
in textual mode.

Git index will be represented as a directory, so that you can use cp,
rm instead of git add, rm. The same is with stages, each of them is a
directory:
index/ - files that're in stage 0
index/1 - files that're in stage 1
index/2 - files that're in stage 2

Let me explain by example:

$ git checkout branch
#...some editing...
$ git add file1
$ git commit -m "msg"

will be changed to

$ cd branch/tree
#..some editing...
$ cp file1 /mnt/index/
$ cp commit_msg /mnt/index
$ mv /mnt/index COMMIT

So why not to use rm?
Because 'rm -r' firstly removes files under index/, but file removing
under index/ is used for git rm.

The last command commits and moves head of the branch to the new
commit.
NOTICE: Editing a commit of the branch makes it working directory. The
other branches will be read-only until you commit or flush changes.

Merge is done through writing to ctl file. I'm not using `cp branch1
branch2` as gitfs needs to differ merging from editing a file. It's
needed to differ them, because gitfs should be able to represent diff
between conflicting versions.

File-specific log.
You can view file-specific log by:

#we should change to command mode
$ chgrp MAGIC file1
$ echo log > file1
$ cat file1
#Log for the file1

That's it. I hope I could explain my decision.

Thanks,
Manzur

[ron minnich]

Well, *I'm* impressed!

ron

[Federico G. Benavento]

yep, really good stuff!

On Tue, Jun 30, 2009 at 7:18 AM, ron minnich<rmin...@gmail.com> wrote:
>
> Well, *I'm* impressed!
>
> ron
>
> >
>

--
Federico G. Benavento

[Devon H. O'Dell]

Amazing. Great job, Manzur!

--dho

[Eric Van Hensbergen]

Thanks for taking the feedback constructively. I look forward to
trying your stuff out.
Astounding progress.

-eric

[Roman Shaposhnik]

Hi Manzur!

First of all, let me echo previous posters and say that I'm really
impressed with the quality of proposed model. I believe it is
a very solid attempt in capturing the essense of what Git does
while at the same time mapping it to Plan9 way of doing things.

I would strongly suggest that you expand your examples and
reasoning and turn it into a paper once you have reasonable
amount of implementation ready.

Now for some clarifications.

On Tue, Jun 30, 2009 at 2:31 AM, Manzur<manzu...@gmail.com> wrote:
>
> Hi All!
>
> First of all, I want to thank you all for participating in discussion.
>
> So, last week besides doing what was planned(completing file server
> interface with existing library functions),  I forked the project, and
> created read-only version of gitfs with following layout:
>
> $ mount {myfs repo} mntpt
>
> $ cd mntpt
> $ ls
>   d­rwxr­xr­x M 4 manzur manzur 314 Jun 25 20:22 master
>   d­rwxr­xr­x M 4 manzur manzur 314 Jun 25 20:22 rdonly­gitfs
>
> Each of the above entry is a branch, and each of them contains
> following files:
>
> tree - snapshot of the file tree when commit was executed. You can
> browse it and read files from it.
> parent1 - first parent of commit
> ...
> parentN - Nth parent of commit

Are parents files or subdirectories?

> Git index will be represented as a directory, so that you can use cp,
> rm instead of git add, rm. The same is with stages, each of them is a
> directory:
> index/   - files that're in stage 0
> index/1 - files that're in stage 1
> index/2 - files that're in stage 2

How does these stages map to Git's show/diff numbers?

Thanks,
Roman.

[Dave Eckhardt]

> $ git checkout branch
> #...some editing...
> $ git add file1
> $ git commit -m "msg"
>
> will be changed to
>
> $ cd branch/tree
> #..some editing...
> $ cp file1 /mnt/index/
> $ cp commit_msg /mnt/index
> $ mv /mnt/index COMMIT

This shows promise. I think there are a couple more steps
floating around somewhere, though: a user needs to know
or recall or determine *which* files need to be added.
My proposal for a "status" file was to have the SCM present
that information to the user.

> Each file under some branch will have two modes: command
> and textual. Modes are changed by chgrping to the special
> value. By default, it's in textual mode.
>

> #we should change to command mode
> $ chgrp MAGIC file1
> $ echo log > file1
> $ cat file1
> #Log for the file1

I think this will turn out to be painful in practice. How
about presenting the log for foo.c as log/foo.c?

Dave Eckhardt

[Manzur]

On 1 июл, 06:40, Roman Shaposhnik <shaposh...@gmail.com> wrote:
>
> Are parents files or subdirectories?
>

Parents are directories, and they have the same structure as above.
Moreover, directory name parent[\d] is substituted by tag if there's a
tag for that commit.

> > Git index will be represented as a directory, so that you can use cp,
> > rm instead of git add, rm. The same is with stages, each of them is a
> > directory:
> > index/   - files that're in stage 0
> > index/1 - files that're in stage 1
> > index/2 - files that're in stage 2
>
> How does these stages map to Git's show/diff numbers?

Are you hinting at absense of stage 3? :)
Yes, I forgot it. There should be index/3 as well.

[Manzur]

On 1 июл, 08:03, Dave Eckhardt <davide+goo...@cs.cmu.edu> wrote:
> > $ git checkout branch
> > #...some editing...
> > $ git add file1
> > $ git commit -m "msg"
>
> > will be changed to
>
> > $ cd branch/tree
> > #..some editing...
> > $ cp file1 /mnt/index/
> > $ cp commit_msg /mnt/index
> > $ mv /mnt/index COMMIT
>
> This shows promise.  I think there are a couple more steps
> floating around somewhere, though:  a user needs to know
> or recall or determine *which* files need to be added.
> My proposal for a "status" file was to have the SCM present
> that information to the user.

Why not to use diff for that purpose? Diff between index/ and the
working directory actually shows what you need.

> > Each file under some branch will have two modes: command
> > and textual.  Modes are changed by chgrping to the special
> > value. By default, it's in textual mode.
>
> > #we should change to command mode
> > $ chgrp MAGIC file1
> > $ echo log > file1
> > $ cat file1
> > #Log for the file1
>
> I think this will turn out to be painful in practice.  How
> about presenting the log for foo.c as log/foo.c?

Yes, that's more convenient way to view the log. But example with log
was supposed to show how file-specific operations are done. There're
other file-specific commands that need be executed.
Thanks for the idea, I'll definitely use that.