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

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

[Ian Barton]

> 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 ?
> 
Alan,

Not being a regular git user, I can't help directly with which commands 
you need to use. However, you might find 
http://www.netsplit.com/2009/02/23/revision-control-systems-suck/ 
entertaining.

If you have a git repo that contains a "correct" working version, I 
would suggest that you start from scratch with that. As Bernt suggested 
you should create a repo with no working trees on your usb stick. This 
will just contain the repo i.e. .git and nothing else.

In bzr you can use push to update your repo on the USB stick, so the 
.git contains all your changes. Note this only updates the repo, you 
won't see any of your files in the directory on the usb stick containing 
the repo (they are all in the .git repo).

I think that part of the proble is that push in git doesn't work like 
you might expect (see the ranting link above). You may need to use got 
clone the first time you edn your changes, after that I think push 
should work.

Take your usb stick to Machine B and create a working branch from your 
usb stick.

In bzr this would be something like:

bzr branch /media/usbstick/my_git_repo/ ~/Documents/org

In git I think you need to use clone, with a similar syntax

This would create a working copy in ~/Documents/org. Note that bzr would 
want to create the org directory, so whatever target directory you 
choose shouldn't exist initially.

You can then work on your org files on Computer B and do a git commit 
when you have finished. In bzr a simple bzr push would update the repo 
on your usb stick and I think that got works the same way.

You can then take your usb stick to Computer A and do a git pull to get 
your changes. When you have finished working on Computer A doing a git 
commit and a git push should update the repo on the usb stick.

I have almost finished an article on how I use bzr to keep my org files 
in sync. I am aware that most people using org probably use git, so I 
have been trying to give my examples using both bzr and git. However, I 
too find some aspects of git confusing.

If we can sort out the correct way to use git, I promise to finish my 
article and send it to worg!

Ian.

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

[Alan E. Davis]

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

One more point:

May I ask for an example of a case when branching would make sense in the
context of this synchronization usage of Git?

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: 568 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:

> One more point:
>
> May I ask for an example of a case when branching would make sense in
> the context of this synchronization usage of Git?

Here are a couple:

I don't use multiple branches for my org repos.  But I do use branches
extensively on coding projects.

------------------------------------------------------------------------

I code for a living.  When working on a project I make a branch for a
topic during development and keep the changes related to that topic
isolated on the topic branch until they are ready to be merged into the
main development branch.

My repo looks something like this:

o--o--o--o--A (master - main development branch)

Then I start a new topic creating a branch at A 

o--o--o--o--A (master)
             \
              o--o--B (topic B)

New work can be added to the master branch as other development topics
are merged in

o--o--o--o--A--o--o (master)
             \
              o--o--B (topic B)

Now when I need to take this code with me I push master and the topic
branch(es) to the usb stick so I can continue working on them offline.
I'm free to continue development on my laptop and move the changes back
to my workstation.

When I merge the topic branch into the main branch I delete the topic
(and remove it from the usb stick repo).  The topic branch stays as a
set of discreet commits all directly related to the topic.  Commits for
other topics go on other branches (yes I have branches that are simply 1
commit).  Branches are cheap and easy in git.  I rarely work directly on
the master branch.

Having the flexibility to keep topic branches clean and isolated from
other changes is a huge help when developing multiple features on a
project.  You can merge in only the topics that are ready and keep
working on the others.  You are free to merge topic branches into the
main branch in whatever order makes sense for the project.

------------------------------------------------------------------------

On another project I have 68 topic branches which are merged into 4
integration branches in various combinations.

I only push the master, and 4 integration branches to the usb stick.  I
can recreate any topic branch easily from the integration branch history
and I find it alot easier to manage all of these branches by only
tracking the integration branches on the usb stick.

------------------------------------------------------------------------

Another example is code for a website.  If this is deployed on a test
webserver and a production webserver you can easily set up 3 branches as
follows:


o--o--o--o--o--o--o--o      master (common code)
          \     \
           \     o--o--o--o test-config
            \
             o--o--o        prod-config

where test-config is the set of configuration changes to make the
website work on the test environment and prod-config is the set of
changes to make the system work in production.

You would normally want all 3 branches available so that if you make
some change that required updating configuration information on the test
and prod branch you can keep the changes isolated on the appropriate
configuration branch.

To actually run the code in test you make an temporary integration
branch (test) at master and merge in the test-config branch.  The result
should be ready to use on your test environment.  When you're done
testing you can simply delete the test branch.  It's a throw-away since
you can recreate it again easily as needed.

------------------------------------------------------------------------

I don't use this added flexibility on my org-mode repos.  I don't have
topics where it makes sense to isolate changes while organizing things.
I use git with org-mode mainly as a safety net so I can easily do oops
type edits, as a backup of my org notes, and an easy way to synchronize
between my workstation and laptop.  My organizational notes are all over
the place by nature and trying to separate that into discreet topics in
org-mode doesn't make any sense to me.

Does any of that help?

-Bernt

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