git rebase時に、rebase前のコミットについていたtagはどうなる

Hidenori Goto | COO and CTO at KabuK Style @hidenorigoto

あれ、rebaseするとコミットに関連付けていたタグは消えちゃうんでしたっけ・・・。

ぐるぐる系SQL @bleis

@hidenorigoto 消えないですよ

ぐるぐる系SQL @bleis

gitkを使っているのであれば、--allすれば見えるとかそういう

Hidenori Goto | COO and CTO at KabuK Style @hidenorigoto

@bleis ありがとうございます。自分の理解不足ですｗ http://bit.ly/ijXpCl 履歴をさかのぼってコミットを1個追加して、masterへ戻って追加したコミットへリベース、みたいな操作をしたので、新しいコミットが作られたということでいいんでしょうか。

ぐるぐる系SQL @bleis

@hidenorigoto そんな感じです。tagはcommitオブジェクトのハッシュを指すだけのものなので、rebaseした際に新しいcommitオブジェクトが作られてもそのままになる、とそんな感じ

ぐるぐる系SQL @bleis

@hidenorigoto 4-29が指してるcommitオブジェクトには、親のcommitオブジェクトのハッシュが記録されていて、4-29-preのコミットを指しこんだことで、4-29が指してるcommitオブジェクトとは別のcommitオブジェクトが必要になった(続

ぐるぐる系SQL @bleis

@hidenorigoto なんでかというと、Gitではcommitオブジェクトは一回作られたらその内容が変更されないから。変更できているように見えるのは、単に新しいcommitオブジェクトが作られて、そちらを指すようになるからです。(続

ぐるぐる系SQL @bleis

@hidenorigoto で、今回みたいにtagとか打ってあると、そのtag自体は前のcommitオブジェクトを指したままになるので、gitkすると消えたように感じる、と

ぐるぐる系SQL @bleis

・・・というような感じの話を名古屋Ruby会議02ではしようと思ってます

Hidenori Goto | COO and CTO at KabuK Style @hidenorigoto

@bleis なるほど、丁寧にありがとうございます。ということは、こういった書き換えを行う場合はtagを付け直す必要があるということですね。

ぐるぐる系SQL @bleis

@hidenorigoto そういうことになります