FYI: please file review requests on gitlab now
mail at milianw.de
Fri Feb 1 16:45:10 GMT 2019
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:
> 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
> 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:
-> (at least) two remotes:
origin == official repo
fork == your fork
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
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.
mail at milianw.de
More information about the KDevelop-devel