Re: File Systems and a Theory of Edits

[Michael Nahas <mike.nahas@gmail.com>]

Michael,

I've been thinking about it and "git mount" is the right idea.  I like
it a lot.  In fact, the most common usage of "git checkout" can be
totally replaced by "git mount".

The other usage of "git checkout -- file" can be replaced by "git cp".

Mike


On Sun, Jul 31, 2011 at 5:13 PM, Michael Nahas <mike.nahas@gmail.com> wrote:
> Why not "git mount" indeed!
>
> At work, I have 3 very active branches and a slow build system.  Right
> now, when I switch to a new branch, I have to rebuild everything.
> Being able to "git mount" 3 snapshots in 3 directories with three
> different build outputs would make switching branches faster.
>
> 3 working trees would be even better.  I've been wondering if I can
> make another working trees by creating a .git/ directory and
> symlinking to the .git/objects and ./git/refs of my current
> repository.  (I could use the environment variables GIT_INDEX_FILE and
> GIT_WORKING_TREE, but that would require setting and resetting them.
> Or using a different shell.)
>
> So a true "git mount" that allowed mounting editable branches would be
> very useful to me.  (Although, if it wasn't for that crappy build
> system, I prefer a single working tree.)
>
> Mike Nahas
>
>
> On Sun, Jul 31, 2011 at 1:21 PM, Michael Witten <mfwitten@gmail.com> wrote:
>> On Sun, Jul 31, 2011 at 14:15, Michael Nahas <mike.nahas@gmail.com> wrote:
>>> I believe the solution for xargs may be John D.'s solution - to
>>> "mount" the snapshot as a file system.  And the "mount" command in git
>>> is "git checkout".  (Now, I almost want to rename "git checkout" to
>>> "git remount"!)
>>
>> Why not just `git mount', though? We could have different mount points
>> too, so that it's easy to work with multiple `snapshots' at once (in
>> the spirit of bazaar and mercurial, as well).
>>
>> Perhaps `git umount' could be used to make the repository bare.
>>
>> In any case, I always find myself wishing that the standard interfaces
>> would make it easier to base an operation on a snapshot that is not
>> yet mounted as the working tree. It can be quite cumbersome to switch
>> the contents of the working tree.
>>
>