On Fri, Jan 24, 2020 at 4:26 PM <d...@gnu.org> wrote: > > On 2020/01/24 13:57:33, Dan Eble wrote: > > On 2020/01/24 13:45:50, dak wrote: > > > Hoo yes. That kind of extensive change is going to hurt anyway > given the > > > current burst activity level. It will likely suck either way. Do > you have > > > particular dependencies yourself, Dan? > > > > I have a bunch of private branches (contexts, rehearsal marks, warning > clean-up) > > that I would like to get on with rebasing. Normally, once I'm pretty > sure that > > a change of mine will be pushed, I'll just rebase to it locally, but > with this > > one, I don't want to start until it's in master. > > > > If you want help handling Han-Wen's patches tomorrow, you can delegate > some to > > me. > > Well, I should be able to handle them well enough. It would be > preferable if Han-Wen would provide Git-formatted patches (Rietveld is > missing out on commit messages unless you consider scooping them up from > the description as such, and while I would make sure that issue numbers > are in the title lines, I think future rebases/merges at least for > Han-Wen himself would work better if I work from original commits rather > than original diffs). And then it makes little sense distributing those > patches to more than one person.
this goes back to what we discussed in Salzburg, namely that our tooling is clumsy. Having a gerrit or GH/GL based workflow would let us review and exchange diffs as native Git commits, which simplifies a lot of things. I'm happy to push my stuff to some git branch somewhere, if that helps you. BTW, Why do we insist in associating each review with a sf.net issue, even if there is no related bug? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
