On Fri, Jun 26, 2009 at 10:54 AM, Francisco J.
Ballesteros<[email protected]> wrote:
>
>>
>> But suppose we even bite the bullet and
>> have all the junk managed by gitfs. What's
>> the FS action to correspond to:
>> $ git add file1 file2 file3
>> $ git commit -m"Change #1"
>> ?
>>
> You would touch file1, file2, file3, rm file4
But that's not how "git add" works. You never
add ahead of time. What you do is -- you edit
existing files, and you compile, etc. Then you
tell git which files are expected to be part
of the next commit by doing git add.
So, as far as a the FS-view is concerned I still
want all of my files to there. That's why your
suggestion of "rm file4" (and I suppose you
forgot "rm file5") is not acceptable. Those files
have to remain visible in the FS-view.
> Then, after mk clean if you don't want binaries,
Wait! I don't want to do mk clean. That's not helpful
at all. I'm in the middle of project development and
all I want is to commit a few changes to a permanent
history and you ask me to do mk clean everytime
I want that?
> you'd go to /mnt/trees/ and say
> mv <sha1> clone
>
> (clone would commit and then rename sh1 to the right name).
That might be a reasonable first step of doing things, but
it is also too much "cd'ing here and there". In fact, it is no
better than writing custom messages to custom files.
Oh, and that also doesn't cover the case of merges (IOW,
a single commit having two [or more] parents).
> Regarding the comment for commit, you can have a fake
> /mnt/trees/<sha1.README> or whatever
> so that you could edit it, write whatever you have to say, and then
> commit would use that as
> the comment.
Sure I can. But than it wouldn't we Git, would it?
> In fact I'd not use shaN as the names.
When I said shaN, what I really meant was treeish, if you're familiar
with Git terminology. Could be a name, could be anything else:
http://book.git-scm.com/4_git_treeishes.html
> I mean, you could cd into that if that's
> waht you know but I think I'd make the name a name. Not too git, but
> more friendly.
> It's easy to keep an index so the user could
> echo sha myname >>index
I don't think I understand that.
> An alternative I'm thinking about is this:
>
> cd /mnt/trees
> sha1 there is considered read only
> Then you decide to work on sha1 and do a
> mv sha1 your-symbolic-name
> you add, remove, edit files.
I like this part, yes. More on that later.
> you could handle commit as I said above.
Well, it could be just me, but I don't think it is convenient. Or,
at least, it is no more convenient than writing custom messages
to custom files.
> In any case, these are just ideas. I hope it might help to make it more
> close to an actual FS than it would be having to issue multiple ctls.
>
> In particular, I see more natural editing a COMMENTS or README file
> to tag commited trees than to use a ctl, and being able to use the tree as
> seem
> instead of having to remember which files to add, remove etc.
I believe that it'll be much easier to expose commits and treeish objects
as first class citizens. Treeish is just a node in your DAG. Commits are
links in that same DAG. Now, may be, the trouble we are having is
partially due to the fact that DAGs don't fit all that well in FSese.
So, lets suspend the R/W ideas for the moment and answer a very
basic R/O question: what's the best way to represent commits topoly
in a filesystem? The best I can come up with right now is something
like is an alternative root called commits with the following structure:
% cd /mnt/commits/<treeish>
% ls
tree parents children message.txt author.txt committer.txt
This is straighforward, but still doesn't answer a basic question
of how to build a commit topology in cases where there are
multiple parents for a single commit. I don't know of anything,
but a ctl file accepting messages that could help here.
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
-~----------~----~----~----~------~----~------~--~---
