[Bf-committers] Cycles-Baking - 1st round of code review

Julien RIVAUD (_FrnchFrgg_) frnchfrgg at free.fr
Sun Mar 23 11:03:19 CET 2014


Le 22/03/2014 23:43, Dalai Felinto a écrit :
> Dear all,
>
> I just submitted the bake-cycles branch for review:
> https://developer.blender.org/D421

I know I'm repeating myself, and I'm aware I'm not a blender dev and you 
chose your code policies as you saw fit, but:

That's not good practice at all to develop in a side tree then commit as 
a huge "all changes squashed into one" patch. And even more it is not a 
good format for reviewing.

Should a bug have crept in that huge commit you'll be very sorry because 
bisect will only give you "the bug was introduced among these 10000 line 
changes" instead of "the bug was introduced by this 50-line commit, 
which does exactly that single modification for that reason explained in 
the commit message".

The branch should be reviewed as a series of commits, 
rebased/tweaked/rewritten until it is satisfactory, then merged into 
master with a non-ff merge (that is you still have a merge commit even 
if git doesn't need one) where you put the message you would have put in 
the huge single commit.

It would be acceptable if the branch was rebased/rewritten until 
satisfactory, then just pushed with linear history on top of master. Not 
as good, because you loose the information that all these patches belong 
together, and you loose the possibility to explain why the feature is 
good, how it works from a wide point of view, etc...
But it is far less ugly than a single big commit, maintenance costs-wise 
at the very least.

I thought the idea behind git migration was to enable devs that already 
used git to interact more sanely with the master repo, instead of hiding 
their work with git and submitting patches with SVN as everybody else did.

Instead, what happened is that you changed your backend to git, but devs 
still only submit big patches, completely ignoring what tool they used 
to develop, and ignoring all good practice that tool would have brought. 
Apart from the easier cloning, most work still occurs exactly as it did 
before, and that's bad. (I purposedly ignore the happy few that know/can 
push multiple commits at once).

The main problem I see for now is Phabricator itself, because it doesn't 
correctly support git workflow (you cannot even export a real git patch 
out of it, it outputs SVN-style patches, with no information about 
commit parents, messages, etc.), so unless you have push access and 
decide to ignore review process, you cannot really send a new feature as 
a list of self contained, small commits with an explanatory message for 
each.

I don't know if Phabricator Differential is able to cope with patch sets 
and to propose an easy to use interface for them but the current 
situation is less than ideal to say the least. And it's not the first 
time I saw this pattern, or the last I expect.

>
> For simple changes/fixes feel free to push (or send a pull request)
> directly to my github repository:
> https://github.com/dfelinto/blender-git/tree/bake-cycles
>
> For general review and discussions is probably better if we centralize
> it in developer.blender.org.
>
> For bugs/issues I would like to use my github too, at least until the
> code is 'master'-ready:
> https://github.com/dfelinto/blender-git/issues?labels=bake-cycles&state=open
>
> Thanks,
> Dalai



More information about the Bf-committers mailing list