Skip to content
Snippets Groups Projects

simplify git-annex to LFS migration guide

Open username-removed-71118 requested to merge anarcat/gitlab-ee:patch-4 into master

What does this MR do?

This simplifies the git-annex to git LFS migration guide by removing references to direct/indirect mode.

I do not believe it is necessary to switch between indirect and direct mode: uninit does all of that for us. We also show how to do a simple backup.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • mentioned in merge request !1230 (merged)

  • This simplifies the git-annex to git LFS migration guide by removing references to direct/indirect mode.

    @anarcat this process was triple checked and the indirect mode didn't work. Why exactly are you proposing these changes? Are you sure they will work for most environments? :worried:

    Adding a backup process before beginning is a good idea indeed :smiley:

    cc/ @axil @marin

  • @anarcat thanks!

    I do not believe it is necessary...

    Have you indeed tested this procedure? With what git-annex version?

  • This simplifies the git-annex to git LFS migration guide by removing references to direct/indirect mode.

    @anarcat this process was triple checked and the indirect mode didn't work. Why exactly are you proposing these changes?

    Because it is simpler and "worked for me".

    I have had numerous bad experiences switching large git-annex repositories between direct and indirect mode. In the original procedure, that roundtrip is down twice, which is bound to be slow and potentially catastrophic.

    Furthermore, the original document says "Since Annex files are stored as objects with symlinks and cannot be directly modified, we need to first remove those symlinks." Yet we do not need to switch to direct mode to do that: uninit is exactly designed for that purpose.

    Are you sure they will work for most environments? :worried:

    Now that's the key question - are there unit tests of specific environments you had trouble with? There may be problems with earlier versions of git-annex, that, for example, didn't have uninit. But that's not what's mentioned here...

    In my experience, switching to direct mode is just looking for trouble.

  • Thanks @anarcat

    Because it is simpler and "worked for me".

    I understand, but we'd need to double check your process. Technically speaking, a process needs to be reproducible to be considered standard.

    How about adding your process as an alternative to ours? You can add your reasons there, explain the requirements, the highlights and the lowlights, and add your steps according to your method. @axil do you think it would be better this way as well?

    Edited by username-removed-236961
  • @anarcat thanks!

    I do not believe it is necessary...

    Have you indeed tested this procedure? With what git-annex version?

    I have tested my procedure with two different repositories with git-annex 6.20170101-1+b1 on Debian 9 stretch/stable.

    Thanks @anarcat

    Because it is simpler and "worked for me".

    I understand, but we'd need to double check your process. Technically speaking, a process needs to be reproducible to be considered standard.

    Of course. I was assuming that my tests were sufficient, but I understand if you guys ran more test and have more confidence in the existing procedure.

    How about adding your process as an alternative to ours? You can add your reasons there, explain the highlights and the lowlights, and add your steps according to your method. @axil do you think it would be better this way as well?

    Sure, that makes sense. At this point, I think i'm more likely to split up my changes in different parts to at least get the backup procedure in, if not just ditch the whole thing. :)

    Thanks

  • @anarcat your contribution is great, of course, but we need to be cautious and make sure we're checking what's defined in our documentation, which represents GitLab. :wink:

    I think i'm more likely to split up my changes in different parts to at least get the backup procedure in,

    Sure, let's keep the backup procedure for both methods. :)

  • okay, so i rerolled an update which limits the changes to the core procedure and just adds a backup and a branch cleanup procedure. it also adds a missing lfs install call from the short version.

    i still think indirect/direct switching is unnecessary and would love to hear why and how you had trouble without it. but i'm not going to argue over this...

  • Robert Speicher mentioned in commit d3e79985

    mentioned in commit d3e79985

Please register or sign in to reply
Loading