Re: Re: MORE: Using git via USB for personal org dir and other data files

Re: Re: MORE: Using git via USB for personal org dir and other data files

[Alan]

     [Thank you to Bernt for the *clear* explanation of using branches!]

     I seem to be moving out of the woods with this, and for the most
     part, the experiment has been going smoothly.  However, I've run
     afoul of permissions, a bugaboo that was mentioned in an earlier
     post on this topic.   

     I established a bare git repo on the USB drive, from a reasonably
     clean tree.  Pushing changes went well later on.  

     I cloned this repo onto the second machine, edited quite a bit,
     but was  dismayed when  I tried to push: an error message
     indicated that some file couldn't be written.  So far,  the
     problem seems to be permissions.  Preliminary checking shows that
     the group and user IDs are numerical on the flash drive,
     corresponding to the ID of the user who originally cloned the
     repo.  

     I have a tentative plan of action, but I know nothing about the
     use of permissions with git.  

        1. I have established a group "git" with a high group number,
           so I can set create the same group on the work machine,
           with the same group number.  (I think it's too complicated
           to change user numbers at this point).  My users on the two
           machine have different user names.  It would be pretty
           complicated right now to change the user's ID number.

        2. I am setting the group permissions as read and write.

	   # chmod -R g+w /media/BLUE/org.git

        3. Does this make sense?


     This is a great thing.  I want to put a whole bunch of work in such
     a repo.  

     Thank you for the help.  


      Alan 

      
-- 
Alan Davis

"An inviscid theory of flow renders the screw useless, but the need for
one non-existent."                    
    ---Lord Raleigh (John WilliamStrutt), or else his son, who was also a
       scientist.  

Re: Re: MORE: Using git via USB for personal org dir and other data files

[Bernt Hansen]

Changing the permissions and using a group shouldn't be necessary.

If you're using Linux to mount the usb stick the 'user' option makes all
of the files on the drive owned by the person that mounts it.

,----[ /etc/fstab ]
| /dev/sdb1 /usb vfat defaults,user,noauto,shortname=mixed 0 0
`----

Then it just works :)

-Bernt

Alan  <lngndvs@gmail.com> writes:

>      [Thank you to Bernt for the *clear* explanation of using branches!]
>
>      I seem to be moving out of the woods with this, and for the most
>      part, the experiment has been going smoothly.  However, I've run
>      afoul of permissions, a bugaboo that was mentioned in an earlier
>      post on this topic.   
>
>      I established a bare git repo on the USB drive, from a reasonably
>      clean tree.  Pushing changes went well later on.  
>
>      I cloned this repo onto the second machine, edited quite a bit,
>      but was  dismayed when  I tried to push: an error message
>      indicated that some file couldn't be written.  So far,  the
>      problem seems to be permissions.  Preliminary checking shows that
>      the group and user IDs are numerical on the flash drive,
>      corresponding to the ID of the user who originally cloned the
>      repo.  
>
>      I have a tentative plan of action, but I know nothing about the
>      use of permissions with git.  
>
>         1. I have established a group "git" with a high group number,
>            so I can set create the same group on the work machine,
>            with the same group number.  (I think it's too complicated
>            to change user numbers at this point).  My users on the two
>            machine have different user names.  It would be pretty
>            complicated right now to change the user's ID number.
>
>         2. I am setting the group permissions as read and write.
>
> 	   # chmod -R g+w /media/BLUE/org.git
>
>         3. Does this make sense?
>
>
>      This is a great thing.  I want to put a whole bunch of work in such
>      a repo.  
>
>      Thank you for the help.  
>
>
>       Alan 
>
>       
> -- 
> Alan Davis
>
> "An inviscid theory of flow renders the screw useless, but the need for
> one non-existent."                    
>     ---Lord Raleigh (John WilliamStrutt), or else his son, who was also a
>        scientist.  

MORE: Using git via USB for personal org dir and other data files

[Alan E. Davis]

[-- Attachment #1.1: Type: text/plain, Size: 2765 bytes --]

Regarding the synchronizing of directories on two or more machines, using a
USB Stick.  Further questions after a bit of experimentation.

I am currently keeping two workstations up to date via a USB flash drive,
and have had, variously, both good and bad luck. Here are some questions:

1.  I understand the idea, finally, of using a "bare" repo on the fiash
drive, at least in part.  But what will I do if the bare repo fails to merge
because two versions are pushed or pulled to it from the two machines, of a
file.  I've wasted a bit of time and now have gotten "meld" installed as the
mergetool.  Still, sometimes even that doesn't work.  Today I have two flash
drives in use, one that was working fine to update from one machine, but
won't even accept a file from the other.  I have clumsily deleted the old
version from the USB drive, and copied over the other version, done git rm
<oldfile> git add <file> and git commit -a, but the file refuses to
install.  I'm not going to ask this as a primary question, because I think I
need to just understand the underlying idea of using a bare repo, and not
editing it at all.

2.  I have had poor luck with push.

3.  For this simple usage, is it even useful to think about branches, and if
so, how should branches be used?

4.  Is it wiser to fetch than to pull?  I have seen this suggested, but
don't understand the use of fetch.


Here is a rough idea of what I think I need to do now.  Please comment on
any ommissions or problems:

At home, on my primarly workstation:
1. cd to a directory with a good tree (perhaps ~/org) already under git
control.
2. insert the USB drive (I have a label "BLUE" on my usb drive.  On my
gnome/ubuntu box, it automounts as /media/BLUE)
3. git clone --bare . /media/BLUE/org.git
4. git remote add BLUE /media/BLUE/org.git
5. ??  git push BLUE (master?)

Now at work, I am on the other workstation:
1. git clone /media/BLUE/org.git
2. can I now do this?: git remote add BLUE /media/BLUE/org.git
2. work
3. git push BLUE ???
4.

Back at home
1. git fetch BLUE ??  or git pull BLUE ??



I am confused at a couple of points here.

Much of the above I have gleaned from three posts by Bernt Hansen.  Other
sources on line include some postings on the very problem of syncing
machines using git.

Can I pull from /media/BLUE/org.git ?

Well, perhaps this is enough confusion for now.  Thanks for all the
suggestions on this list.  I think it's going to work, and I'll expand this
to other directories as well.

Alan


-- 
Alan Davis

It is undesirable to believe a proposition when
there is no ground whatsoever for supposing it is true.
    ---- Bertrand Russell
They are ill discoverers that think there is no land, when they can see
nothing but sea.
    ----   Sir Francis Bacon

[-- Attachment #1.2: Type: text/html, Size: 3035 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: MORE: Using git via USB for personal org dir and other data files

[Bernt Hansen]

Hi Alan,

The best way to test drive all this stuff is just make some throw away
repos to play with.

$ mkdir /tmp/junk
$ cd /path/to/your/org/git/repo
$ git clone --bare . /tmp/junk/org.git
$ cd /tmp/junk
$ git clone org.git home
$ git clone org.git work

Now you have 3 repos in /tmp/junk
  work - pretends to be your repo at work
  home - pretends to be your repo at home
  org.git - your bare repo on the usb stick

Now cd work, do stuff, git commit and git push
then cd home, git pull, do more work, git commit, git push
etc.

Since these are just junk repos for experimenting you don't have to
worry about messing them up and you can just rm -rf /tmp/junk when
you're done.

Comments follow:

"Alan E. Davis" <lngndvs@gmail.com> writes:

> Regarding the synchronizing of directories on two or more machines, using a USB Stick.  Further questions after a bit of experimentation. 
>  
> I am currently keeping two workstations up to date via a USB flash drive, and have had, variously, both good and bad luck. Here are some questions:
>
> 1.  I understand the idea, finally, of using a "bare" repo on the fiash drive, at least in part.  But what will I do if the bare repo fails to merge because two versions are pushed or pulled to it from
> the two machines, of a file.  I've wasted a bit of time and now have gotten "meld" installed as the mergetool.  Still, sometimes even that doesn't work.  Today I have two flash drives in use, one that
> was working fine to update from one machine, but won't even accept a file from the other.  I have clumsily deleted the old version from the USB drive, and copied over the other version, done git rm
> <oldfile> git add <file> and git commit -a, but the file refuses to install.  I'm not going to ask this as a primary question, because I think I need to just understand the underlying idea of using a
> bare repo, and not editing it at all. 
>

You never merge on the bare repo.  You do all of the merging on your
working copies (home or work).  Then pushes to the USB stick are always
fast forward changes which just work.  If you rebase and rewrite history
you can force update on the usb stick with push -f -- just make sure you
really want to overwrite the history on the usb stick with what you have
now before you decide to do that.

>
> 2.  I have had poor luck with push.
>
> 3.  For this simple usage, is it even useful to think about branches, and if so, how should branches be used?

I use topic branches all the time.  If I want to put a branch on the sub
stick I use:

  $ git push usb my-branch

When you fetch from the usb repo it will create any new branches as
usb/my-branch.

You can also delete branches when you're done with them with

 $ git push usb :my-branch

to remove it from the usb stick repo.  To remove them from your working
directory later you can use

 $ git remote prune usb

which finds any remote branch names (usb/*) that exist in your working
directory that no longer appear on the remote (usb stick) and deletes
them from your working directory repo.

> >
> 4.  Is it wiser to fetch than to pull?  I have seen this suggested, but don't understand the use of fetch.

pull = fetch + merge (or fetch + rebase) depending on the branch setup.

I personally fetch first, and if git status stays it's a fast forward
merge then I pull.

> >
> Here is a rough idea of what I think I need to do now.  Please comment on any ommissions or problems:
>
> At home, on my primarly workstation:
> 1. cd to a directory with a good tree (perhaps ~/org) already under git control.
> 2. insert the USB drive (I have a label "BLUE" on my usb drive.  On my gnome/ubuntu box, it automounts as /media/BLUE)
> 3. git clone --bare . /media/BLUE/org.git

This creates the repo with all of your branches in this working directory.

>
> 4. git remote add BLUE /media/BLUE/org.git
> 5. ??  git push BLUE (master?)

You don't need this after the clone - the new clone on the usb drive is
up to date - it doesn't hurt though :)

> >
> Now at work, I am on the other workstation:
> 1. git clone /media/BLUE/org.git
> 2. can I now do this?: git remote add BLUE /media/BLUE/org.git

After you clone the repo in step 1 the remote is added automatically
with the name 'origin'.  This would add a second remote (at the same
location) but with a different name (BLUE).  You really don't need to do
this -- you can just use the remote 'origin' but again it doesn't hurt
anything.

>
> 2. work
> 3. git push BLUE ???

That pushes any new commits on master back to your BLUE remote.  The
push will fail if the update is not a fast forward.  (ie if you added
stuff to the usb stick from somewhere else since you fetched last then
the push will fail).  In that case you need to fetch + merge first (git
pull) and resolve any conflicts you might have.

> 4.
>
> Back at home
> 1. git fetch BLUE ??  or git pull BLUE ??
>

I would just do git pull (which is fetch + merge)

If you fetch only you'll have this:

o--o--H (tip master on home)
       \
        o--o--W (time of usb/master with new commits from work)

and after a fetch you can easily see this in gitk

$ git gitk master origin/master  (or if you don't have tons of branches
                                  just gitk --all)

If you pull it will advance H (your master on the home repo) so it is at
W.  This is normally what you want to do.

>
> I am confused at a couple of points here. 
>
> Much of the above I have gleaned from three posts by Bernt Hansen.  Other sources on line include some postings on the very problem of syncing machines using git. 
>
> Can I pull from /media/BLUE/org.git ?

Yes you can (and for this setup I would recommend that as your normal
mode of operation).

AT work:
  $ git pull BLUE                                   [*1*]
  <hack> <hack> <hack> <commit> <commit> <commit>
  $ git push BLUE
  <pull usb stick and go home>
At home:
  <plug in usb stick>
  $ git pull BLUE
  <hack> <hack> <hack> <commit> <commit> <commit>
  $ git push BLUE
  <pull usb stick and go to work>
  <go to step [*1*]>

>
> Well, perhaps this is enough confusion for now.  Thanks for all the suggestions on this list.  I think it's going to work, and I'll expand this to other directories as well.

As I said up front - just play with it in /tmp until you're
comfortable.

Regards,
Bernt

Re: Re: MORE: Using git via USB for personal org dir and other data files

[Sebastian Rose]

Bernt Hansen <bernt@norang.ca> writes:
> Hi Alan,
>
> The best way to test drive all this stuff is just make some throw away
> repos to play with.
>
> $ mkdir /tmp/junk
> $ cd /path/to/your/org/git/repo
> $ git clone --bare . /tmp/junk/org.git
> $ cd /tmp/junk
> $ git clone org.git home
> $ git clone org.git work
>
> Now you have 3 repos in /tmp/junk
>   work - pretends to be your repo at work
>   home - pretends to be your repo at home
>   org.git - your bare repo on the usb stick

I'll stay with monotone for this exact reason and purpos. It's great
with USB, FAT and so on. No mess since three years now and it has the
best of all user interfaces.


So here, again, my monotone advertising:

No thinking and reading and asking and than again reading... - just
using. That's what a SCMS is for. The docs (just one PDF) will get you
started after 10 minutes and you'll only have refer to the docs in very
rare cases in the future because of mtns UI.

You'll not even have to add your key file to ssh-agent by hand -
monotone does that for you once it knows about it. Don't add something -
just commit...

I only use git with servers on the net, where it plays great. Also, the
`git gui' is one of the best GUIs for RCSs around.

For the USB stick case, it's worth to mention, that monotone needs no
.mtn-ignore file, just to know, that *~ files have to be
ignored. Permissions are handled (even if the stick is FAT formated) as
well as empty directories. Simply the best designed RCS around IMHO. No
need to say, that monotone handles copys and renames (with history).

USB:

  $ cd org/
  $ mtn -d /path/to/desired/localdb db init
  $ touch file.c
  $ mtn add file.c
  $ mtn commit -m'message'

Now the USB:
  $ cp /path/to/desired/localdb /media/BLUE

That's all.

The first time we sync with /media/BLUE/database, we tell monotone, to
use this repo as the default. No fiddling with `remotes', `origin'...

  $ mtn sync --set-default /media/BLUE/localdb

Bang - you're done once for ever.

  # On the other computer:
  $ cp /media/BLUE/localdb /path/to/desired/localdb
  $ mtn -d /path/to/desired/localdb co org
  $ cd org
  # edit add and so on
  $ mtn commit -m'message'
  $ mtn sync --set-default /media/BLUE/localdb
 
Later on just call
  $ mtn sync


Databases are small (in my tests _much_ smaller than git or mercurial
repos), can even be accessed using SQL (it's a sqlite database) and
extend it's functionality through LUA (per workspace), trust is managed
per workspace...

One feature I like with monotone is the _MTN/log file. You may gather
commit messages while working, which makes it realy easy to document
your work in great detail and keeps you documenting them. Never forget
to document a change or the reason for it anymore. There's a little
elisp file I wrote make `add-change-log-entry' search for _MTN/log and
use it. I've bound `mtn-add-change-log-entry' to F8 (see
http://www.emacswiki.org/cgi-bin/emacs/sr-monotone.el).

I even use monotone and git in conjunction a lot. Monotone for USB, git
for the servers (since I have to). While git has great features, those
are not what I need for my workflow.

git always throws warnings and errors here, when I try to `git clone
--bare' on FAT formated USB sticks (didn't try with the new 1.6.1.3
version, that's in Debian testing since a week).



Regards,

-- 
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover
Tel.:  +49 (0)511 - 36 58 472
Fax:   +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Http:  www.emma-stil.de

Re: Re: MORE: Using git via USB for personal org dir and other data files

[Bernt Hansen]

Sebastian Rose <sebastian_rose@gmx.de> writes:

> git always throws warnings and errors here, when I try to `git clone
> --bare' on FAT formated USB sticks (didn't try with the new 1.6.1.3
> version, that's in Debian testing since a week).

The only issue I ran into was when I mounted the USB stick with Linux's
default options.  I need to specify the option shortname=mixed so that
it doesn't create 'head' instead of 'HEAD' in the repo on the USB stick.

,----[ part of my /etc/fstab ]
| /dev/sdb1 /usb vfat defaults,user,noauto,shortname=mixed 0 0
`----

After that everything worked great for me.

-Bernt

Re: Re: MORE: Using git via USB for personal org dir and other data files

[Sebastian Rose]

Bernt Hansen <bernt@norang.ca> writes:
> Sebastian Rose <sebastian_rose@gmx.de> writes:
>
>> git always throws warnings and errors here, when I try to `git clone
>> --bare' on FAT formated USB sticks (didn't try with the new 1.6.1.3
>> version, that's in Debian testing since a week).
>
> The only issue I ran into was when I mounted the USB stick with Linux's
> default options.  I need to specify the option shortname=mixed so that
> it doesn't create 'head' instead of 'HEAD' in the repo on the USB stick.

Aaaahaaa, Bernt is our git god :) That's exactly the reason for failing
to create repos it seems. I remember, it head to do with `HEAD'!

Thanks a lot. Now I only have to find out how to add that option to a
modern system, that uses no fstab for USB devices. Google should shed
light on this quickly.

Even if I like monotone, I still don't like to use two systems for one
project. Now I can use git for git projects, which is nice.



Thanks Bernt!



> ,----[ part of my /etc/fstab ]
> | /dev/sdb1 /usb vfat defaults,user,noauto,shortname=mixed 0 0
> `----
>
> After that everything worked great for me.
>
> -Bernt
>

This was one of those days I learned more on the emacs-orgmode
mailinglist, than in `real' life :) where I met no unicorn again.


Regards,

-- 
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover
Tel.:  +49 (0)511 - 36 58 472
Fax:   +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Http:  www.emma-stil.de

Re: Re: MORE: Using git via USB for personal org dir and other data files

[Sebastian Rose]

>> ,----[ part of my /etc/fstab ]
>> | /dev/sdb1 /usb vfat defaults,user,noauto,shortname=mixed 0 0
>> `----
>>
>> After that everything worked great for me.
>>
>> -Bernt
>>
>
> This was one of those days I learned more on the emacs-orgmode
> mailinglist, than in `real' life :) where I met no unicorn again.


Start gconf-editor and navigate to
system->storage->default_options->vfat

edit the key 'mount_options' and change it's value to:
  [shortname=mixed,uid=]

That's it.

Now, indeed,

 git clone -l --no-hardlinks --bare org/ /media/BLUE/git/org

works like a charm.

Thanks again Bernt!

Best,
-- 
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover
Tel.:  +49 (0)511 - 36 58 472
Fax:   +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Http:  www.emma-stil.de

Re: MORE: Using git via USB for personal org dir and other data files

[Alan E. Davis]

[-- Attachment #1.1: Type: text/plain, Size: 1485 bytes --]

 Thank you Bernt (and Sebastian):

I now understand that it is necessary to pull the changes to the alternate
tree before pushing.  This will make a big difference in the future, I
believe.  It worked as advertized on the /tmp/junk experiment.

I think the other point I had missed, that would be necessary in an FAQ or
tutorial, is that it is necessary to initially clone each of the working
trees, on each machine, from the bare repo on the USB flash drive.  Then it
now makes sense to me to name that as org.git, to distinguish it as a bare
repo.  And once the working trees are cloned from there, then the org.git on
the USB drive is recognized automatically as "origin".  That point eluded
me.   And that git pull will perhaps automatically find origin.

Meld is starting to make sense too.  Thought it would be nicer to have a
tool that would be able to make simple updates from two edits on the same
file if they don't conflict.  Usually, this will not be the case.

Now, is it useful to use the switches on an ext2 formatted USB drive, as
follows?

    $ git clone -l --no-hardlinks --bare . /path/to/usb/stick

Thank you again,

Alan


-- 
Alan Davis

"An inviscid theory of flow renders the screw useless, but the need for one
non-existent."                     ---Lord Raleigh (John William Strutt), or
else his son, who was also a scientist.

It is undesirable to believe a proposition when
there is no ground whatsoever for supposing it is true.
    ---- Bertrand Russell

[-- Attachment #1.2: Type: text/html, Size: 1755 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: MORE: Using git via USB for personal org dir and other data files

[Bernt Hansen]

"Alan E. Davis" <lngndvs@gmail.com> writes:

>  Thank you Bernt (and Sebastian):
>

I'm just trying to help :)

>
> I now understand that it is necessary to pull the changes to the alternate tree before pushing.  This will make a big
> difference in the future, I believe.  It worked as advertized on the /tmp/junk experiment. 

Great!

> >
> I think the other point I had missed, that would be necessary in an FAQ or tutorial, is that it is necessary to initially
> clone each of the working trees, on each machine, from the bare repo on the USB flash drive.  Then it now makes sense to
> me to name that as org.git, to distinguish it as a bare repo.  And once the working trees are cloned from there, then the
> org.git on the USB drive is recognized automatically as "origin".  That point eluded me.   And that git pull will perhaps
> automatically find origin.

git pull and git push use the default remote 'origin' if none is
specified.

>
> Meld is starting to make sense too.  Thought it would be nicer to have a tool that would be able to make simple updates
> from two edits on the same file if they don't conflict.  Usually, this will not be the case.
>
> Now, is it useful to use the switches on an ext2 formatted USB drive, as follows?
>
>     $ git clone -l --no-hardlinks --bare . /path/to/usb/stick

I've never used -l --no-hardlinks when creating repos on my usb stuck.
vfat filesystems don't support hard links and you can't make use of
hard links across filesystems.

There is lots of information available from git man pages (ie. git clone
--help) which describes what all of the options do.

Regards,
Bernt

Re: Re: MORE: Using git via USB for personal org dir and other data files

[Sebastian Rose]

Bernt Hansen <bernt@norang.ca> writes:
>>     $ git clone -l --no-hardlinks --bare . /path/to/usb/stick
>
> I've never used -l --no-hardlinks when creating repos on my usb stuck.
> vfat filesystems don't support hard links and you can't make use of
> hard links across filesystems.

That's true :)

I just copy this from my every-day-git.org. Everything I don't work on
anymore goes there to keep the number of workspaces at a minimum. I tend
to start a lot of little projects as test balloons (or just out of
curiousity) and keep them for reference. I'm always afraid to lose some
trick I found and that does not make it into one of my real projects :)

But even then, --no-hardlinks is not needed. It's a bad habbit even, since
I waste disk space that way. Removing .git in my workspace will never
remove any of the cloned (local, on same filesystem) repos, since files
_are_ hard links, and the data is reachable as long, as at least one
hard link exists (that's the difference between hard links and symbolic
links).

At least that's how I understand hard links on Linux.


`du' does take that into account:

$ mkdir test
$ cd test
$ touch file.c
$ cat /some/file > link.c
$ du -h
16K	.
$ ln file.c link.c
$ du -h
16K	.
$ ln link.c link2.c
$ du -h
16K	.
$ ls -l
insgesamt 36
-rw-r--r-- 3 sebastian sebastian 8988  1. Mär 16:02 file.c
-rw-r--r-- 3 sebastian sebastian 8988  1. Mär 16:02 link2.c
-rw-r--r-- 3 sebastian sebastian 8988  1. Mär 16:02 link.c


No matter how many hard links I add: the disk usage stays the
same. One more point for git!

OK, I'll adjust my habbits :)


Best,

--
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover
Tel.:  +49 (0)511 - 36 58 472
Fax:   +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Http:  www.emma-stil.de