On Fri, Jun 26, 2009 at 8:32 PM, Roman Shaposhnik<[email protected]> wrote: > > 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
I know > 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. You implement the Fs, therefore you could know which files are written/added/removed. Although perhaps you are thinking on a more simple program for gsoc. > 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. I may commit a new version after removing file 5 (that´s what I meant). I really removed it from my local tree. >> 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? Well, let the binaries get it then :) > 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. I think I´d keep a tree plus a DERIVEDFROM or something file that I could read to see if there´re more than one parent. In fact, perhaps just a STATUS file reporting everything you want (including, say, a line like derived from: /git/versiona /git/versionb ) So that I could cat the status and then paste the path, e.g., to cd into it. I agree that the mv thing is perhaps as obscure as a ctl can be. But I was just trying to throw away ideas about this (perhaps noise). I though it could be fun to make gitfs maintain also the local copy (perhaps supplying it as a path when you start it) so that you could forget about which files you added, which ones, removed, etc. That was what bothered me most the last time I used a version control system, having to keep in mind that it was not a bunch a files, but a version control system. Thus, if for the typical checkout - work - commit sequence you can forget everything and just use the file tree, it would be much easier to use. For complex commands it´s likely you are going to need ctls in any case, but how many times do you require them?). In any case, ignore this if it doesn´t makes sense for you, just use whatever I might have said that you find useful. It´s just that I have played in the past with the idea although I never did anything about it. (rant?) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
