On Mon, Jan 31, 2011 at 4:27 PM, Lukast dev <> wrote: > > boud: > ...
> o but then the development branch should never be deleted, otherwise > we have one big commit that nobody can every bisect anymore and never > figure out the history of > 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. o development branches may not compile sometimes, do we want to see these commits in master? o cherry-picking is effectively an equivalent to rebasing, especially when there are conflicts present. 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. 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. -- Dmitry Kazakov
_______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
