Workflow Idea for 4.10

[Kevin Ottens]

Hello,

On Saturday 17 March 2012 19:23:27 Stephen Kelly wrote:
> Am I the only person who values browsable history? Repositories where you
> can run gitk and see something useful.

No, you can count me partly in. :-)

That said, you shouldn't make the issue worse than it really is. Part of that 
is a tool issue, we have no good way to vizualize such an history... the real 
question is: yet? If that's something we can count to see solved later on then 
no big deal, if not then we have a large upcoming problem which will explode 
as we use more branches.

> What Aaron proposed is exactly what CMake does. The result is that if you
> run gitk, you can't see the actual patches. If you run gitk --first-parent
> on master you *only* see merges, so the only information you can see is the
> name of the branch that got merged (which is in the git commit message), not
> the actual patch, and to see the patches in a topic you have to know the
> name of the topic.
> 
> You can't just browse the commits, so you can't practically do post-commit
> review with gitk, as I do. Using email for that really doesn't work for me
> for one thing. If I want to look at commits that I vaguely know exist but I
> don't know which topic branch it came from, I should be able to browse fot
> that. I have the git repo in front of me, so I should be able to use it
> without jumping through too many hoops.
> 
> We're going to have small repos after splitting, not large ones. Having a
> branch and a merge per patch commit in small repos is way overkill. Let's
> have readable history instead please.

As I pointed out earlier on, *for KDE Frameworks* and because of the 
splitting, the currently proposed workflow is clearly overkill in most cases. 
That was my main motive to step back and reevaluate the situation.

> [...]
> I think people think that if they're committing in a branch which is not
> master, that they are 'free' and their commits don't have to build, and that
> all that matters is that the end result actually gets merged, but that's
> not really true. We should have history which is both readable and
> buildable imo.

+1, that's the important point which is often overlooked when leaning toward 
"let's feature branch often". The other one which is kind of linked to that, 
is that it makes it much easier for someone to end up being more isolated, 
working in the branch for too long reducing communication.

> Part of the way we get to that is by not encouraging everyone to make lots
> of branches, encouraging people to have branches in scratch repos if they
> want to have a branch, and encouraging people to submit to master self
> contained patches which build instead.

Yep, one of my investigations taking into account the "profile of the 
contribution" (as mentionned previously) instead of the "profile of the 
component" leans toward a similar solution.

> Making commits that don't build and making mistakes is understandable of
> course especially for new people (and I sometimes make commits that don't
> build too), but we should at least aim higher.

Agreed.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120318/9281bf02/attachment.sig>