#9 Workflow to keep forked repo updated?

It is not clear to me how you envision updating a fork of a repository without being able to specifying different remotes within gin. As far as I understand the concept, there can only be a single remote per repo clone, which would usually be my personal fork of the project. How do I get changes from upstream to my fork? Of course I could start tweaking on the git(-annex) level, but this is not how it is supposed to work, right? Thanks for clarifying!

The client doesn't support multiple remotes (yet) but it's planned for the next batch of changes, along with alternative storage locations for annex data.

Dear Julia first thanks for your feedback. Its honestly appreciated!

To expand a bit on @Achilleas short answer. We like to think of the client as a thing to make your live easier, however, git and git-annex, while both can be quite cumbersome to use, are tools ultimately meant to be used by the end user.

We don't think of them as backend things that nobody should use. To the contrary, we can only encourage everybody to learn how to use them. Ultimately they are more powerful or at least more flexible than something we provide as a layer around them.

Forking and pull requests, while an everyday thing for most software/hacking people are IMHO rather advanced concepts (for the non git users) and while upstream merging will sooner or later (sooner) be supported in the client doing it with annex directly is not painful.

In that sense, and if you allow me to expand on your words :-), I would like to say that using annex directly is not "tweaking" GIN it's using it as it is meant to be :-).

In case you need further assistance getting it going dont hesitate pushing us. In principle its as simple as :

adding a git remote (git remote add upstream git@gin.g-node.org:/user/upstream.git) annex copying the required files from your repo (assuming they are not there yet) git annex copy <path> --from=origin and annex copying the file to upstream: git annex copy <path> --to=upstream

see here

All the Best

Christian

Hi Christian, thanks for the detailed description. I was not aware that you actually consider using git-annex as well as gin commands in combination as proper usage. I was indeed hesitating using git-annex because I didn't know what this would break on the gin level.

I followed your description and added another remote (I think you meant 'git remote add upstream git@gin.g-node.org:/user/repo.git', right?) and got it to work like this.

However I didn't expect that when having multiple remotes registered gin upload is automatically pushing to all remotes available and not only to origin. Is this intended?

Just to clarify things:

I was not aware that you actually consider using git-annex as well as gin commands in combination as proper usage.

Well, we kind of advertise one or the other :-). Mixing will probably work most often but no guarantees here. Its also probably not well tested. If the only thing gin-cli does is the authentication your safe!

I think you meant 'git remote add upstream git@gin.g-node.org:/user/repo.git', right?

Indeed I did not put the remote name in there and assumed upstream later....

I didn't expect that when having multiple remotes registered gin pload is automatically pushing to all remotes available and not only to origin. Is this intended?

Honestly, I was also kind of surprised that this works (@achilleas might know more here). One pure annex workflow, however, could be as stated above (This, of course, requires a working key setup - which might be useful anyhow ).

I'd be interested to know what commands you did in git-annex and what you did with gin. By default, the gin client pushes to the default remote only. Of course, given all the wonderful configurations in which a git repository may find itself, it's hard to predict exactly what will happen sometimes.

Hi Achilleas, here is what I did after forking and using gin to clone my repo fork:

• I added an additional remote using git git remote add upstream git@gin.g-node.org:/user/repo.git
• I pushed two files to upstream using git annex git annex copy <path> --to=upstream, these files already existed in origin
• I created a new file and uploaded it using gin gin upload <new_filename>. This file appears now in origin as well as upstream master

In case you want to have a look at the details:

• the repos are https://web.gin.g-node.org/NeuralEnsemble/ephy_testing_data and https://web.gin.g-node.org/sprenger/ephy_testing_data
• <path> is 'neuralynx/Cheetah_v5.6.3/plain_data/CSC*.txt'
• <new_filename> is 'config.yml'

Ok, it makes sense now. The upload worked with config.yml because it's not an annexed file, so it got synced to all remotes without needing to do a git annex copy.

Internally, gin upload performs a sync (upward only), which does a git push to all remotes. The content, however, is copied only to origin, using git annex copy, the same way you did. A git annex sync --content would copy every file to every remote.

Thanks for the info. I'm in the process of working out how to best handle multiple remotes in the gin client now, so this should become easier.

There's been a number of updates to this since the last time we spoke here.

1. Multiple remotes are handled much better now in gin-cli. Version 1.0 added the ability to manage remotes, including adding directory remotes (a directory that can serve as a content store and git remote). See gin help add-remote.
2. With multiple remotes configured, the gin upload command only pushes to the default remote (since Version 1.2). You can see a list of configured remotes with the default remote highlighted using gin remotes.
3. You can change the default remote using the gin use-remote command.
4. You can specify a specific remote to upload to using the --to flag in upload, e.g., gin upload --to myfork datafile.nix.
5. Specifying all as the remote name pushes to all configured remotes gin upload --to all datafile.nix (all is a reserved remote keyword that can't be used as a custom remote name).