사실 다들 한 번 쯤은 포터블 모드로 애플리케이션을 사용해야 할 때가 있을 것입니다. 그리고 저는 좋지 않은 이유로 에디터를 그렇게 사용하고 있습니다. 하지만 아쉽게도 제 최애 Git GUI 클라이언트인 Git Fork는 에디터의 경로를 지정하는 기능이 지원되지 않았습니다.


환경

이번 글에서는 저는 저만의 Atom-Editor를 사용할 계획입니다. 그렇기 때문에 Visual Studio Code와 같은 타 에디터와 같은 경우에는 다루지 않습니다.

  • Editor: Atom-Editor 1.44
  • Git GUI Client: Git Fork 1.50

현재 Atom-Editor의 최신 버전인 1.48 버전은 버그가 너무 많은 관계로 구 버전을 메뉴얼하게 설치해야 하는 상황이 발생했습니다. 그래야 자동으로 업데이트가 진행되지 않습니다. 그렇기 때문에 일단 외장 하드에 에디터 소스코드를 압축을 풀어주었습니다.

문제 인식하기

저와 같이 에디터를 메뉴얼하게 설치를 한 경우에는 다른 프로그램에서 에디터가 설치되었는지 알 수가 없습니다. 모든 폴더를 찾아보는 것도 비효율적이기 때문에 기본적인 설치 경로나 레지스트리만 찾는 것이 일반적입니다. 하지만 인식되지 않으면 저장소 탭에서 바로 에디터를 열 수 없는 불편함을 감수하기는 싫었습니다.

시작하기 전에 검색 먼저해보기

그래도 기본적으로 Google이나 GitHub Issue를 먼저 찾아보아 비슷한 사례나 해결방법이 있는지 찾아보도록 합니다. Git Fork와 같은 경우는 프라이빗 소스로 운영되는데 Git Fork에서 About 메뉴의 Issue Tracker 항목으로 GitHub 이슈트래커에 접근할 수 있습니다. 아쉽게도 Google에 비슷한 결과를 표시되지 않았습니다. 클라이언트 이름도 이름이라 그런가 봅니다.

GitHub Issues 탭에서는 기본적으로 모든 플래그를 해제하고 검색해야 합니다. GitHub는 Google이 아니기 때문이죠. 그리고 키워드도 설렁설렁하게 잡아주고 조금만 살펴보면 원하는 항목이 보입니다. 이미 글을 쓰는 시점에서는 시간이 많이 지나 있어 저는 GitHub에 이미 해결책을 올려두었습니다.

문제 해결

저는 기본적으로 일단 Symlink를 생각했습니다. 바로가기를 쓸 수도 있었겠지만 그 경우에는 바로가기는 일종의 파일 개념에 더 가깝기 때문에 저에게 맞는 요소가 아닙니다. Symlink는 바로가기보다는 가상의 파일 폴더 마운팅에 더 가깝습니다. 그렇기 때문에 시도하지도 않은 바로가기보다는 훨씬 더 다른 프로그램들이 자연스럽게 동작할 것이라고 생각했습니다.

Windows에서는 Symlink를 mklink 명령어로 만들 수 있습니다. 아래와 같이 원래 설치되는 경로에 원본 경로로 Symlink를 생성해줍니다. 생성되면 아래 사진과 같은 모습을 볼 수 있습니다.

mklink /d "C:\Users\Seia\AppData\Local\atom" "D:\Extensions\Applications\atom-x64-windows\Atom x64"

생각보다 쉽게 해결되어 이제 Git Fork를 사용해 그 뒤로도 계속 편안하게 코딩을 시작할 수 있게 되었습니다. 정말 다행이네요. 원래 있던 작은 기능이라도 없어지니 얼마나 불편한지 모르겠네요.

끝입니다. 그럼 좋은 코딩되세요.