On Mon, Jun 29, 2009 at 3:58 AM, Dave Eckhardt<[email protected]> wrote:
>
> I think having gitfs export writable working
> directories is worth pursuing.  Here are some
> suggestions:

Agreed. But not, necessarily as part of *this* GSOC project.

> 1. gitfs provides in a "status" file its idea of
> "the expected future" of a working directory, kind
> of like /proc/*/ns:
>
> add foo.c
> add foo.8
> modify mkfile # no details, just the fact

This status *file* starts to look awfully like a subdirectory
to me. Any reason that you prefer it to be a file instead
of working-dir/.git/*  ? (IOW, you do all FS operations
on the content of a working-dir and you have them mapped
to files visible under working-dir/.git/*).

> 2. The user can provide guidance/settings, e.g.,
>
> % echo ignore foo.8 > ctl
>
> means that "status" will no longer contain the
> "add foo.8" line, but will now include "ignore foo.8".
> These "settings" are as sticky as they should be,
> whatever that means.

Any reason not to adopt the git way of honoring
.gitignore files?

> 3. At any point you can "cp status ctl" if you like
> what you see.

If a status is really a subdirectory called index,
you can commit it the same way, can't you?

> 4. One command is "log _filename_" which says where to
> find the next commit message.  Like "ignore", it doesn't
> "do anything" except stick around as a setting.
>
> 5. When you want to commit, "echo commit > ctl".  This
> could be set to fail if the log file hasn't been declared
> or doesn't exist.  Also, maybe it should fail if the
> "status" file contains pending "add" commands (this
> protects you against checking in a broken build, where
> somebody expects foo.c to exist but you forgot to add
> it).

Now this starts to sound awfully complicated :-(

> As a slight modulation, any time the declared commit
> file is deleted one could be synthesized based on a
> diff of the working directory against its parent.
>
> I don't know how naming of directories should work,
> but I assume once a directory has been committed
> a read-only version named by a hash will turn up.
> Anyway, when possible, "parent/" should refer to
> the previous commit, so "diff parent/foo.c foo.c"
> and "diff parent/parent/foo.c foo.c" should work.

So... is the answer to my DAG question: don't worry
about anything but trees?

Thanks,
Roman.

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

Reply via email to