Front page | perl.perl5.porters |
Postings from August 2012
* Karl Williamson <public@khwilliamson.com> [2012-08-04T18:58:14] > The implication of my first paragraph are that if you rebase, do a > merge commit, and someone in the meantime has pushed to blead, your > push will fail, and your merge has to somehow be redone, as the 'git > pull -rebase' will lose the fact that it was a topic branch. Assuming I understand correctly, that is true — but since the topic branch will have been rebased for the first merge, it is quite unlikely that the re-merging will really be any non-trival amount of work, isn't it? commit's -C switch means you won't need to retype any message, etc. I don't mean to make a big deal of a small detail, but sticking to "effectively linear history even with merges" is, I think, easy. -- rjbsThread Previous