Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Pierre Habouzit writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)"):
> Raphael is wrong to ask you to rebase, he's _really_ wrong about that,
> but *you* also are wrong to ask him to pull (aka fetch + merge). The
> usual way is that _you_ merge the current state of dpkg in your work so
> that _you_ solve the conflicts and issues, and _then_ mainline can see
> how it looks and look at the cleansed diff.
I definitely agree that I should be the one to do the merge. So at
least twice already I have merged mainline into my tree and published
the result.
Ie, I agree with you. That's exactly what I want to happen.
I'm very happy to do that merge again, if I have some assurance that
it's not just wasted work.
In fact, at this stage I don't even want any effort from Raphael and
Guillem. All I want is permission. They have already granted me
physical commit access but they have made it clear that they don't
want me to merge my branch, or to commit freely, and that they will
consider it abusive if I simply push a merged triggers branch.
All I want is for Raphael or Guillem to say `oh all right then'.
I will then merge mainline into my branch, do any conflict resolution
necessary, and give it a quick test to make sure nothing seems to have
been broken in the meantime. Then merging my branch back into
mainline is, as you say, just a fast forward - so I will simply do
that, and push the result.
And really I would like Raphael and/or Guillem to simply confirm that
I'm a full member of the team.
> IOW, you have to merge master, preferably in a new branch than your
> trigger-new one, like a master-pu-triggers or whatever, and if mainline
> is pleased or can read that patch (that I'm sure isn't _that_ big) they
> _then_ will be able to merge that branch that would just be a
> fast-forward.
The resulting patch is still big (3-4kloc of diff) because triggers is
a big feature. The size will not change much depending on what
precise revision it's based on.
> Note that they may ask you to rework this merge if they had done some
> further commits, but if you mkdir .git/rr-cache then git is able to use
> recorded images of already solved conflicts so that merging the same
> conflicts again and again doesn't costs you any time.
IME I can just merge from mainline into my branch, and it all works
completely fine and I never need to do any rework. This is, after
all, what a distributed vcs is for.
Ian.
Reply to: