<br><br><div class="gmail_quote">On Mon, Jan 31, 2011 at 4:27 PM, Lukast dev <span dir="ltr"><></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
boud:<br></blockquote><div>... <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
o but then the development branch should never be deleted, otherwise<br>
we have one big commit that nobody can every bisect anymore and never<br>
figure out the history of<br></blockquote><br clear="all"></div>I'm not sure the latest statement is true. If the branch is merged into master and then deleted, the history of the branch will still be there. You will see a "ring" in `gitk --all` interface.<br>
<br>o development branches may not compile sometimes, do we want to see these commits in master?<br>o cherry-picking is effectively an equivalent to rebasing, especially when there are conflicts present.<br>o cherry-picking and rebasing is not always clean. Example: imagine you did a merge from master to branch in the middle of the development of the branch. Rebasing (cherry-picking) of such a branch is not safe.<br>
<br>As for me, i'm almost agree with sebsauer. If you have a small local branch that will never be published, just rebase it. If you have once published your branch, you should do no rebasing, cherry-picking or other rewriting of history.<br>
<br><br>-- <br>Dmitry Kazakov<br>