
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s tech blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, distributed training, and data engineering.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Thu, 16 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/jujutsu/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/2026-07-16-git-history-command</guid>
    <title>git history — Git이 rebase 옆에 놓은 실험적 history 재작성 명령어</title>
    <link>https://www.youngju.dev/blog/2026-07-16-git-history-command</link>
    <description>Git 2.54(2026-04-20)에 git history라는 새 명령어가 실험적으로 들어왔고, 2.55(2026-06-29)에서 fixup 서브커맨드가 추가됐습니다. reword/split/fixup 세 가지 흔한 history 재작성 작업을 인터랙티브 rebase 없이 명령 한 줄로 처리하고, 대상 커밋의 자손 브랜치들을 원자적 ref 트랜잭션으로 한꺼번에 갱신합니다. 메인테이너 Patrick Steinhardt는 커밋 메시지에서 이 기능의 동기로 Jujutsu 같은 경쟁 VCS에서 스택 브랜치 사용이 흔해졌다는 점을 직접 지목합니다. 다만 이건 아직 실험입니다 — 머지 커밋이 있는 history에서는 동작하지 않고, 충돌이 날 상황이면 설계상 그냥 중단하며, 훅을 전혀 실행하지 않습니다. 이 글은 실제로 들어온 것, 밑바닥이 sequencer가 아니라 git replay 위에 지어졌다는 사실, fixup의 세 갈래 병합 방향, 그리고 이 한계들이 풀리려면 왜 first-class conflicts가 필요한지를 1차 출처로 정리합니다.</description>
    <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>git</category><category>version-control</category><category>jujutsu</category><category>rebase</category>
  </item>

    </channel>
  </rss>
