#24 using "normal" git UI

hi,

I have been using GIN as a normal git repo for some time without problems (I have not used git annex commands), using Rstudio or sourcetree to commit, push and pull (both mac and windows 7 pro).

I saw the remarks about using git commands instead of gin ones, so if the file names are clean (no special character) and it not using git annex, I will have no problem, right?

How should I then add big files:

• Could we use the browser function: then the files are not accessible directly on the laptop repository, I would need to keep a different copy somewhere else ?
• using the shell "gin upload .": then I need to install the gin command line function, and go through quite a workflow (see below)?
• is there another cross-platform option, that would only rely on git?

Any thought ?

please check this for integration of solution 2: https://gin.g-node.org/jcolomb/testbigfiles/src/master/workflow_ginupdate.md

I saw the remarks about using git commands instead of gin ones, so if the file names are clean (no special character) and it not using git annex, I will have no problem, right?

Yes, there should be no problem with using it like you described.

To answer your main questions:

Could we use the browser function: then the files are not accessible directly on the laptop repository, I would need to keep a different copy somewhere else?

You would need to use the gin client or git-annex to download the content. That's the most straightforward way of getting the file content from GIN.

using the shell "gin upload .": then I need to install the gin command line function, and go through quite a workflow (see below)?

Yes, this is basically the same as uploading them through the web interface. When you clone the repository using git alone, you get pointer files with no content for the annexed data and would have to gin get-content or git annex get.

is there another cross-platform option, that would only rely on git?

We do support webdav but it's not very well tested: https://gin.g-node.org/G-Node/Info/wiki/Dav. This only provides read access to repository files.

Your git repository would still only have pointer files in it, but you would be able to access the big files with their content directly through the mounted DAV directory. I don't know how well that fits your workflow.

Note: The repository you linked to seems to be private. Can you add me as a read-only collaborator (if you would like me to read it)?

made it public, sorry.

whooa, so using gin upload. did erase the file on my computer ?? That seem quite problematic ! no copy made on the harddrive before modifying the file ?

By the way, why were there 3 branches created?

whooa, so using gin upload. did erase the file on my computer ?? That seem quite problematic ! no copy made on the harddrive before modifying the file?

Sorry, I think I didn't explain it clearly. gin upload . wont delete or remove anything. It's equivalent to a git annex add ., git push, and git annex copy. What I meant previously was that if you later git clone the repository on another computer, the annexed files will be empty pointer files at first and then you will have to run git annex get to download the content of these big files.

By the way, why were there 3 branches created?

Git annex creates two branches to store its metadata (content locations and repository keys). From the git-annex documentation.

A file's content can be transferred from one repository to another by git-annex. Which repositories contain a given value is tracked by git-annex (see location tracking). It stores this tracking information in a separate branch, named "git-annex". All you ever do with the "git-annex" branch is push/pull it around between repositories, to sync up git-annex's view of the world.

Git annex also creates two more branches when a git annex sync is performed called synced/master and synced/git-annex. The purpose of these is to be able to push to a working git-annex repository from another one in a decentralised fashion and then merge on the receiving end using git annex sync. The reasoning is documented in more detail here.

Some comments on your linked workflow document:

gin update . will push all changes, adding big files with git annexe, small files with git commit, and make all changes.

I guess that's a typo as it should be gin upload ..

NB: there is no special commit message, so I would encourage you to use it only for the big files upload.

Since version 1.9, you can now add commit messages using gin commit -m <message>, before doing a gin upload.

Sorry, I think I didn't explain it clearly. gin upload . wont delete or remove anything.

The files are indeed gone from my computer (I know have the 68kb git annexe link instead of the videos). I am not sure why it happened, but it happened.

If it's a symlink, you can get back the regular file with gin unlock.

Older versions of the gin client would use the git annex default options which convert files to symlinks when added to the annex. This prevents large data files from being modified without first unlocking them. The content is stored in .git/annex/objects and set read-only.

In newer versions (since v1.7, see changes here) files are added in unlocked mode, which behaves more like you would expect, but has the disadvantage that it creates copies of the files in .git/annex/objects and can take up a lot of space. With the newer version, you can change between these two states with gin lock and gin unlock. The locked or unlocked status of a file then needs to be committed to the repository and it is tracked.

ok that was scary, but the data is actually there! maybe worth a note in the workflow documentation ?

Step 8 in the workflow tutorial [1] mentions the locking of files for v1.6 and below.

I suppose it could be made clearer. However, it's no longer relevant in newer versions since the client doesn't lock the files by default.

There are cases where a current gin client might lock files:

• If the git repository and the annex were not initialised by the client itself. In other words, if you are working in a git repository and run git annex init and then start using the gin client, the client will not set its own defaults. By default, git-annex locks files when doing git annex add and then committing.
• If the repository was initialised with an older version of gin client. This is the same situation as above, but in the next release, the client will be able to detect this and offer to update the repository and set the new defaults.

In general, for users that plan to mix gin client and git annex commands, we recommend they read the final section of the client tutorial which describes how the gin client sets up a repository and what can happen if certain configuration options aren't as expected.

• [1] GIN Usage Guide - Basic workflow: https://gin.g-node.org/G-Node/Info/wiki/GinUsageTutorial#the-workflow
• [2] GIN Usage Guide - Using git and git-annex directly: https://gin.g-node.org/G-Node/Info/wiki/GinUsageTutorial#using-git-and-git-annex-directly