FYI: please file review requests on gitlab now

[Milian Wolff]

On Monday, January 28, 2019 12:12:52 PM CET René J.V. Bertin wrote:
> >I do this all the time with KDE, Qt and commercial projects I work on. This
> >is not a special workflow at all, quite the contrary - it's the norm!
> Hmmm, I might reconsider if someone paid me big(gish) bucks for doing this
> kind of thing.
> 
> For tip-of-the-iceberg reference: my patchfile repositories for the KF5
> frameworks and KDevelop:
> https://github.com/RJVB/macstrop/tree/master/kf5/KF5-Frameworks/files
> https://github.com/RJVB/macstrop/tree/master/kf5/kf5-kdevelop/files
> 
> The KF5 packaging effort could easily be a fulltime job in itself, and will
> always need patchfiles which will never be upstreamed for a variety of
> reasons. Maintaining dedicated branches for all of them is just going to
> add overhead to what I already have to do in order to maintain them,
> overhead that requires time and energy I simply no longer have. In addition
> we are talking here about adding remotes which also have to be kept
> up-to-date.
> 
> That doesn't mean I don't already do things this way for a select few
> patches in ditto projects, but in practice I will end up contributing less
> if the possibility to upload a patch for review from KDevelop disappears.

Instead of having a git repo of patches, which is a huge waste of time, have a 
bunch of forks with your custom patches applied. This is what I mean by "use 
git". No, putting patch files into a git repo like you do is *not* how it's 
supposed to be done.

Also, to make this clear, since you are getting it all backwards apparently. 
Here's an example for kdevelop:

path/to/kdevelop
-> (at least) two remotes:
   origin == official repo
   fork == your fork

-> fork/rjvb/master
   this is the master branch (or whatever you want to use) with *all* of your 
custom patches applied, whether you want to upstream them or not
   you never create a merge/review request for this one

-> fork/rjvb/feature_foo
    this is a feature branch with just the patch(es) applied that correspond 
to a specific feature you want to upstream. Send a merge request for that one

Now, you only work in your master and rebase it regularly to stay up2date. 
rebasing will show you when your patches are conflicting / getting outdated, 
you fix them. After rebasing that master, if you want to update one of the 
feature branches too, switch to that branch and rebase it. You won't have to 
redo the conflict resolution thanks to `git rerere`, which is afaik 
automatially enabled nowadays.

So again: your workflow is broken. Do yourself a favor and change it. Don't 
demand us supporting a seriously broken workflow.

-- 
Milian Wolff
mail at milianw.de
http://milianw.de