git workflow draft

[Stephen Kelly]

Michael Pyne wrote:
> 
>> People who are interested in ksslsocket will see the commits.
> 
> You're thinking of CommitFilter. I'm thinking of the kde-commits mailing
> list (i.e. people who didn't *know* they were interested in ksslsocket
> until they saw a "strange" commit).

I wasn't really. It's just as true for kde-commits. People looking for 
strange commits are not going to skip over commits just because they're in a 
batch. 

I know what you're going to say - They weren't looking for strange commits 
until they found one :).

So why would anyone skip over a bunch of 15 commits in knetwork (or wherever 
kssl is) just because they're all in one group? It seems to me like getting 
into purely imaginary issues here.

>> > In addition as Andreas Pakulat mentioned in a response to a
>> > rebase-workflow in kde-scm-interest, this completely deletes the fact
>> > that the development happened in a branch at all (we could simply
>> > retain the old solid/make-it-cool ref so we don't lose that history,
>> > but that would make the repository correspondingly larger).
>> 
>> The assumption that all of the history is useful to have by definition
>> was called into question. I suggested creating useful history so that all
>> history in the release branches is useful.
> 
> Either way is an assumption, but only one of these assumptions involves
> deliberately discarding data. ;)
> 
> What specifically do you mean by "creating useful history" though? i.e.
> what should be done additionally in a rebase workflow to get the useful
> history you refer to?

Do this:



> 
>> Another important point I think is that 'topic branches' will not
>> necessarily be normal, but exceptional. Most KDE developers are used to
>> commit early commit often, and that might translate into 'push early,
>> push often', so we'll end up seeing 2 or 3 commit pushes and very few
>> monsters. I rarely push more than 10 commits and very rarely if ever have
>> pushed more than 20.
> 
> I actually quite agree with you here for the vast majority of topic
> branches. But it also mitigates one of the disadvantages I mentioned in
> merging (the cluttered history), as there won't be too many active
> branches outstanding at any given time, and therefore there shouldn't be
> large problems with tons of branches at once anyways.

I think the most important thing to keep in mind in this whole git workflow 
discussion is that the first iteration is not going to be correct no matter 
what. 

There will need to be changes and adjustments as we go along.

> 
> Regards,
>  - Michael Pyne