Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Vincent Danjean <vdanjean.ml@free.fr>]

Raphael Hertzog wrote:
> Heh, anybody can blindly apply the patches corresponding to the branch
> and attach to it a sane commit message.  If that was the real problem, it
> would most probably already be done and we wouldn't discuss here.
> 
> But Guillem wants to review and understand the code. In this process,
> he will rearrange the changes in smaller logical chunks. 
> 
> If the code had been submitted in that form (easy to review), the branch
> would most probably already have been merged and we would be done.

What about keeping the (bad) real history (so that merging with out-tree
branch will still be easy) AND presenting logical chunks easy to review ?

I imagine the current situation is something as


A0 ---- A1 ----- ... ----- A     mainline branch
 \                \
  B1 ---- B2 ---- .... ---- B    trigger branch with crap history (and several merges from mainline)


Then go to the situation :

A0 ---- A1 ----- ... ------- A ---- P1 ---- ... ---- P6   logical chunks easy to review
 \                \           \                        \
  B1 ---- B2 ---- .... ---- B - M1 --------------------- M final commit to push

with the property that M1, M and P3 represent exactly the same source
tree (but obviously they are not the same commit as they do not have
the same history)

There will still be some commit with crap log (Bx) in the git repo
but, if no one create branches from Bx or M1, one would always be
able to follow an easy to understand path from the base to its
commit (by looking the changes on the Px path and knowing that
the merge M merges two *identical* trees)

  Best regards,
    Vincent