はやみずです
> mergeするときにはそのmerge commitだけについて確認すれば > 良いですがrebaseの場合はpatchが当たるかどうか、動作は > 意図した通りになるかcommit毎にチェックする必要があり > ますよね。 > > http://github.com/hayamiz/twittering-mode/commit/52786fe52d12ca4aaa5ad060bbbfa27e2e3d12d4 > のように大きな更新を越えてrebaseするときはconflictして > なくても意図した配置になるのか気になります。 チェックする回数は増えるかもしれませんが、チェックする絶対量としてはほ ぼ変わらないはずです。rebaseであろうがmergeであろうが、upstreamで大きな 変更が行われていた場合には、どこかのタイミングでその変更とコンフリクト わけですから。 とはいえrebaseをするほうが面倒なのは確かだと思います。しかしその分履歴 を整理された状態に保つことができるので、履歴をたどる必要が生じたときの 作業はやりやすくなると思います。 > git help log > --first-parent > Follow only the first parent commit upon seeing a merge commit. > This option can give a better overview when viewing the evolution > of a particular topic branch, because merges into a topic branch > tend to be only about adjusting to updated upstream from time to > time, and this option allows you to ignore the individual commits > brought in to your history by such a merge. topic branchをmergeするワークフローにすると、--first-parent オプション は必要な情報が落ちてしまうようです。たとえば、今の hayamiz/master で git log --first-parent すると松尾さんの行った new-timeline-spec の変更 のコミットの表示が省かれてしまいます。 また、rebaseをする場合としない場合では、履歴を辿るときに表示される順序 がどうなるのかも気になります。履歴をたどるときに、コミットの系譜が一直 線であるほうがどのタイミングで何が取り込まれたのかが明らかであるように 思います。 At Fri, 08 Jan 2010 03:07:33 +0900 (JST), Tadashi MATSUO wrote: > > 松尾です。 > > > 各commitの妥当性チェックは、本質的には単にmergeするのとかわらないのでは > > ないでしょうか？実作業上の問題としては、ChangeLogが頻繁にコンフリクトし > > てしまうのでその解決が面倒というのはありますが。 > > mergeするときにはそのmerge commitだけについて確認すれば > 良いですがrebaseの場合はpatchが当たるかどうか、動作は > 意図した通りになるかcommit毎にチェックする必要があり > ますよね。 > > http://github.com/hayamiz/twittering-mode/commit/52786fe52d12ca4aaa5ad060bbbfa27e2e3d12d4 > のように大きな更新を越えてrebaseするときはconflictして > なくても意図した配置になるのか気になります。 > > 先程改めてtimeline-specをrebaseしてみましたら > twittering-mode.elのconflictを2回手動修正する必要が > ありました。(ChangeLogは5回) > もっと苦労したような記憶があったのですが、慣れてないせい > だったのかもしれません。 > > > トピックブランチを取り込む際にrebaseすることの利点は、ひとえに履歴のシ > > ンプルさだと思います。リリースノートを書くのに見直しやすいというのもあ > > りますし、あまり事情を知らない人が履歴を見たときにどれが幹なのかわかり > > やすいというのは重要だと思います。 > > どれが幹なのか、についてですがmaster branchのfirst parentを > 辿るものがmainlineになるんじゃないでしょうか。 > > git help log > --first-parent > Follow only the first parent commit upon seeing a merge commit. > This option can give a better overview when viewing the evolution > of a particular topic branch, because merges into a topic branch > tend to be only about adjusting to updated upstream from time to > time, and this option allows you to ignore the individual commits > brought in to your history by such a merge. > > http://progit.org/book/ch6-1.html#ancestry_references > にも > The first parent is the branch you were on when you merged, and the > second is the commit on the branch that you merged in... > と書かれています。 > > git log --first-parent > > で見えるものがそのbranchの幹で、githubのnetwork表示もそれに > 沿ったものになっているように見えます。 > > --- > 松尾 直志 <[email protected]> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > twmode-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/twmode-users ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ twmode-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/twmode-users
