Mark H Weaver <m...@netris.org> skribis: > Leo Famulari <l...@famulari.name> writes: > >> When committing a bug fix with a graft, I think it would be a good idea >> to follow up on some other branch with a commit that makes the same >> change without a graft. >> >> Core-updates was suggested on IRC. This would mean that after each graft >> commit, master would need to be merged into core-updates, and then the >> "ungrafting" patch could be applied. > > Merging those two will be awkward. In my experience, the result of git > automatically merging these two commits is to update the main package > *and* to graft it.
Good point. > For this reason, I think it's preferable for the ungrafted commit to > be on top of the grafted one, i.e. it should remove the graft and > update the origin package in a single commit. > > In practice, this means that after applying the graft to master, master > should be merged into core-updates before applying the ungrafting commit > to core-updates. > > What do you think? Sounds like a good workflow, yes. Regarding builds, it’s really a scheduling problem. We have periodic update branches (gnome-updates, python-updates, core-updates), and Something could tell you whether a change is eligible for one of these branches, so we could batch related changes together. Ludo’.
