mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2018-12-27 16:10:41 -04:00
commit ae5f5414f6
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 22 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
doc/tips/centralized_git_repository_tutorial/on_GitHub/comment_1_98a1986ff2047de981d77755c462b690._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="tomi.ollila@7588dbee63d5e035a85167fe207afb49287f9d1a"
nickname="tomi.ollila"
avatar="http://cdn.libravatar.org/avatar/a794ec01b038c83c4d568d17dc4ceeab"
subject="git config remote.origin.annex-ignore true"
date="2018-12-26T20:33:36Z"
content="""
Something like
git config remote.origin.annex-ignore true
could be useful information in this page. It took me 1.5 hours to figure this out for me (while coding)...
"""]]

8
doc/todo/git_repo_tracking___40__not_storage__41__.mdwn Normal file
View file

@ -0,0 +1,8 @@
If git-annex tracked some information like the repo's remotes, current checkout hash, whether there are uncommitted modifications, branch states, stash state, etc., it seems like it could treat the repo similar to a URL registered for downloading a key. (I've seen the previous threads and agree git-annex should not "store" the repo). With such tracking, I think git-annex could support compelling workflows for managing code/project directories.
A few possibilities:
- Drop a repo for space if the current commit is available in at least N remotes (and all of the repo state is pushed/clean).
- Create branches or tags in an annex that collect a set of version-compatible checkouts for related projects. The commit/tag messages provide a natural place for meta-commentary
- Save and version files that aren't quite junk but don't belong *in* a repo (logs, dumps, backups, editor project/workspace files, notes/to-do lists, build-artifacts, test-coverage/linter stat databases, shell history) alongside the repo, making it easier to have a consistent environment for working on one project across multiple systems.
- Make separate system-specific "master" branches for the main projects directory on each system, then edit and push changes from any other. For example, prep the projects directory on an infrequently-used laptop from your desktop and push/pull the changes.