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

[Stephen Kelly]

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.


Steve.