[Kde-scm-interest] Re: My proposal for a git workflow

[Stephen Kelly]

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.