hook to permit per file merges
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
High
|
Andrew Bennetts | ||
Ubuntu Distributed Development |
Fix Released
|
High
|
Unassigned |
Bug Description
bzr-builddeb would benefit from a clear way to do merges to debian/changelog.
There should be a HookPoint related to merges, and it should have a hook in it called on each merge being done; I've sketched this previously on the list I think, but in case I haven't, I think the following constraints are key:
- multiple plugins should be able to install this hook - it needs to chain
- a plugin that does the merge should be able to indicate it has done so, and then none of the other hooked plugins would be called. OR, some clean way of letting the later callers know that the merge has been attempted and they shouldn't waste that effort.
- there may need to be some sort of ordering, e.g. interactive merges may want to always be last, after automated ones
Related branches
- John A Meinel: Approve
- Vincent Ladeuil: Approve
-
Diff: 960 lines (+672/-74)10 files modifiedNEWS (+16/-0)
bzrlib/decorators.py (+76/-0)
bzrlib/hooks.py (+2/-0)
bzrlib/merge.py (+176/-74)
bzrlib/plugins/news_merge/README (+9/-0)
bzrlib/plugins/news_merge/__init__.py (+73/-0)
bzrlib/plugins/news_merge/news_merge.py (+88/-0)
bzrlib/plugins/news_merge/parser.py (+62/-0)
bzrlib/tests/__init__.py (+1/-0)
bzrlib/tests/per_merger.py (+169/-0)
- Vincent Ladeuil: Approve
-
Diff: 31 lines (+4/-4)2 files modifiedbzrlib/lazy_regex.py (+3/-3)
doc/en/release-notes/bzr-2.7.txt (+1/-1)
Changed in udd: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in bzr: | |
assignee: | nobody → Andrew Bennetts (spiv) |
Changed in bzr: | |
status: | Confirmed → In Progress |
Changed in bzr: | |
milestone: | none → 2.1.0rc1 |
Changed in bzr: | |
status: | In Progress → Fix Released |
The linked branch adds a hook that is intended to address this. It doesn't address "there may need to be some sort of ordering, e.g. interactive merges may want to always be last, after automated ones", but maybe that's not necessary initially, although it does sound like a good improvement to do at some stage.