Git

In some case, we need to send patches that made by other people instead. git send-email command can know this situation by itself by comparing the commit author information and mail sender’s information. In that case, git send-email automatically add From: line pointing the real author of the patch in the body of the mail so that maintainers applying the patches can set the author information correctly. For example, if “Alice alice@abc....

많은 개발 커뮤니티가 요즘은 Github 을 사용합니다만, 일부 커뮤니티는 여전히 메일링 리스트 기반 개발 스타일을 고수하고 있습니다. 리눅스 커널 커뮤니티가 좋은 예가 되겠죠. 이런 스타일에서는 모든 주요 커뮤니케이션이 이메일을 통해 이루어집니다. 패치는 메인테이너와 하나 이상의 공개 메일링 리스트를 향해 메일의 형태로 보내어집니다. 리뷰 또한 이에 대한 답장의 형태로 이루어지지요. 그런데, 일부 이메일 클라이언트는 ``rich user experience’’ 라는 명목하에 원래 내용을 오염시키곤 합니다. 탭을 스페이스로 바꾸거나 html 코드를 집어넣거나 하는 식이죠. 때문에 패치를 보내는 사람은 자신의 메일 내용이 원래 의도한대로 읽는 사람에게 보내지도록 조심해야합니다....

Many communities are using Github nowadays, but some communities still use mailing list based development style. The Linux kernel community would be a good example. In the style, all major communications are made by email only. Patches are submitted to the maintainers and one more open mailing lists as a mail. Reviews are also made as replies to the mail. Because some email clients can distort the original content for so-called ``rich user experience’’ (e....

프로젝트 a 와 프로젝트 b 를 병렬로 진행하고 있었는데, 두개의 리포지토리를 합치고 싶어지는 경우가 있습니다. 예컨대 프로젝트 a 의 성격이 보다 범용이 되었고 프로젝트 b 는 프로젝트 a 를 위한 도구적 성격이 되는 경우가 있겠죠. a 프로젝트에 ‘b’ 디렉토리를 만들고 그 아래 기존 프로젝트 b 의 파일들을 위치하고 싶습니다. 하지만 기존 b 프로젝트의 git 히스토리들도 유지하고 싶습니다. 비슷한 사례로 리눅스 커널 메모리 모델 프로젝트는 별도의 리포지토리[1] 로 개발되었지만 리눅스 업스트림 리포지토리의 tools/ 디렉토리 아래로 머지[2] 되었는데, 이 때 기존 개발 히스토리를 유지했죠....

최근 흥미롭게 보았던 Git Origin Story 라는 제목의 LinuxJournal.com 기사를 번역해 봅니다. 원본 기사는 https://www.linuxjournal.com/content/git-origin-story 에서 보실 수 있습니다. 수년간 리눅스 커널 개발자들이 사용해온 다양한 리비전 컨트롤 방법, Linus Torvalds가 Bit keeper 를 사용하기로 한 결정과 그에 뒤따른 논쟁, 그리고 어떻게 Git 이 만들어졌는가에 대한 글입니다. 처음에, Linus Torvalds는 리비전 컨트롤을 아예 사용하지 않았습니다. 커널에 코드를 기여하고자 하는 사람은 Usenet 그룹에, 나중에는 메일링 리스트에 패치를 올렸고, Linus는 자신의 소스 트리에 그걸 적용했습니다....