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

[Ian Monroe]

On Tue, Feb 15, 2011 at 18:44, Stephen Kelly <steveire at gmail.com> wrote:
> Andreas Pakulat wrote:
>
>> On 16.02.11 00:12:16, Stephen Kelly wrote:
>>> Hi,
>>>
>>> I've added a section for proposed workflows. I think eean wants to create
>>> a couple of proposals too.
>>>
>>> http://community.kde.org/20110213_GitWorkflowAgenda#Proposed_workflows
>>>
>>> Please poke holes in mine and let me know if something just won't work in
>>> it:
>>>
>>> http://community.kde.org/20110213_GitWorkflowAgenda/StevesIdea
>>
>> Whats missing in that idea is why rebasing all the time should be better
>> than merge'ing?
>
> Well, 'all the time' is not really true. I say it's preferred. I can't think
> of any normal cases where merging is definitely better. I would call a long
> lived branch with a lot of contributors an exceptional case by the way.
>
>> Also your proposal creates a purely linear history in
>> master, which means you're completely loosing the information that
>> certain commits belonged to a topic-branch.
>
> If you really think that's useful information to have, then merge with --no-
> ff. I don't know if it can be enforced technically (the tip of a push must
> have two parents or whatever. That would be very annoying), but if it can't,
> having to make it visible from in the history that certain commits were in a
> topic branch once can never be more than a recommended policy. You can do
> it, sure. You can even propose a workflow where it's recommended.
>
>
>> This may be useful in some
>> cases when looking at history as one can easily discard a whole sequence
>> of commits easily by seeing they're coming in through a merge from a
>> topic-branch.
>
> That depends entirely on why you are looking at the history. If you're
> looking for something specific and you happen to know that it didn't happen
> in that topic branch then fine, you might be able to skip a small number of
> commits, but that's a bad idea because you assume the topic branch is
> strictly on topic. What if I do some bug fixes in the branch as well as what
> the topic is about, and that happens to be what you're looking for? Can you
> rely on everyone in kde to keep topic branches strictly on topic? The only
> way you'd know is by looking through the commits in the branch, and then the
> benefit you claim is gone.
>
> To me that benefit seems like a major what-if scenario that is not useful in
> normal cases. Sure, maybe there's exceptional cases where it is useful. I
> think we should focus on benefits to the normal cases.
>
> In normal cases I'd much prefer to see small commits refactoring, then
> adding features instead of large commits experimenting, and fixup commits
> etc just for the reason that 'that's what actually happened'. Creating a
> nice stream of commits makes it possible to find out whether refactoring
> introduced the bug or was it the new feature.

Yep I agree. Joe Coder might think its cool to publish his WIP commits
(facebook generation meets coding!), but no one else does. :)

I also agree with Steve that probably longterm multiple-developer
feature branches are the exception to the rule. If someone is actively
working on some branch (which is probably the state of 90% of  feature
branches: short and sweet) you wouldn't work on it without their
knowledge just to avoid a old-fashioned conflict situation. This
implies the sort of communication that means force pushing is OK.

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.