Ian Monroe wrote: > But allowing force pushing is dangerous and I'm not sure I trust us. > So for that reason alone, I would flip the logic and have it so that > people elect to make branches force pushable (with a prefix like > moshpit or volatile). I'll figure out how to put this on the wiki, > otherwise I just agree with Steve's workflow.
*Shrug*. Both are acceptable. I prefer making them force pushable by default because it encourages the creation of clean history. Making people jump through a hoop of a special branch name (at the beginning) to create clean history is a disincentive. > > From Amarok I know that this whole discussion is a bit moot since > everyone is just going to do whatever they want anyways. And there are > a few other legit exceptions (sometimes rebasing takes a lot more work > then merging to resolve conflicts). It can do, yes. Good use of git rebase --skip can help. I also don't see how git couldn't turn a merge into a rebase with no further fuss. By resolving the conflicts while merging and by git knowing the end result, I'm sure it must be possible. > But I think it's good to have > "here's what your supposed to do and here's why" documented > regardless. > Yes, I suspect that will be the most useful way to get people to create visible/readable history. _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest