![]() ![]() To go into some more detail though, every option/preference we add has a cost. The underlying question here is, what is the fundamental cost of adding an option? One of the foundational pieces of writing for my view point on this comes from Havoc Pennington's Choosing our Preferences which is speaking specifically about GUI applications but they can extend to any kind of tool as well. I have not found a way yet to fetch the git-annex branch shallowly.Why being so severely "conservative"? The first group is already "safe" everything works, but why totally ignoring another group, for who you might just make a cli Who does benefit from your approach? Someone who wants a shallow clone also wants the git-annex branch to beĬloned shallowly and would object if its full history was fetched by that. Git push and git pull still with the problem. Origin/git-annex to FETCH_HEAD) That would leave workflows using (eg, git fetch origin git-annex, which doesĪctually fetch the refs, followed by manually setting Maybe git-annex sync could detect this situation and force fetch That preserves master as a shallow clone, while letting To fetch any other branch from origin will always skip creatingĪll you have to do, then is git config '+refs/heads/*:refs/remotes/origin/*' To "+refs/heads/master:refs/remotes/origin/master". What's going on is, the shallow clone gets set ![]() This does not seem like the best possible behavior, it would be better if,Īfter git-annex sync, it fetched origin/git-annex (either the latestĬommit or all of them) and merged it into the local git-annex branch. So, the clone still doesn't know that it can get the annexed files from origin. In the clone, there is still no origin/git-annex branch, and the git-annexīranch has only the changes that git-annex committed to it in the clone. The clone and the git-annex branch that was synced from the clone. ![]() It contains a merge between the branch that was there before * git-annex -> synced/git-annexĪt this point, the git-annex branch in the remote repository is notĭestroyed. Total 5 (delta 0), reused 0 (delta 0), pack-reused 0 Your branch is up to date with 'origin/master'. Then I ran git-annex init git annex sync: annex init Origin/git-annex branch in the clone, like there normally would be In the clone, that made master be a single commit. Then I cloned: git clone -depth 1 localhost:/tmp/path/to/repo clone The git-annex branch had a couple of commits as well. Where the files were in git, and a newer commit where the files are in Then git rm -cached the files, and git-annex add to add them to I made a repository, added some files to git, and committed. Well, I tried to reproduce this, following your instructions to the extent git-annex-sync could fail and give you the option to add a force flag or work out how to merge things (which shouldn't be too hard when the local metadata is completely empty) Maybe git-annex-init could check if a remote already has annex metadata and pull that. I don't exactly know how this could best be fixed but force pushing without asking isn't a good solution in my opinion. Luckily I was just testing things out and had a backup available but for people who rely on a service like gitlab to access their annex repository when traveling this can end up being a very nasty surprise. To my surprise instead of somehow working out the annex metadata with the remote it just force pushed an empty git-annex branch to the remote. After that I wanted to fetch a few binaries from annex and ran git annex init git annex sync. Because older commits still contain the binaries I did a shallow clone. Then I went on to clone the repo on a different device. I just migrated binaries from native git file tracking to git annex. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |