Thanks for taking the feedback constructively. I look forward to
trying your stuff out.
Astounding progress.
-eric
On Tue, Jun 30, 2009 at 4:31 AM, Manzur<[email protected]> 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
> drwxrxrx M 4 manzur manzur 314 Jun 25 20:22 master
> drwxrxrx M 4 manzur manzur 314 Jun 25 20:22 rdonlygitfs
>
> 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
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Plan
9 Google Summer of Code" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/plan9-gsoc?hl=en
-~----------~----~----~----~------~----~------~--~---
