chiark / gitweb /
wip
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Fri, 27 Jul 2018 11:38:54 +0000 (12:38 +0100)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Fri, 27 Jul 2018 11:38:54 +0000 (12:38 +0100)
talk.txt

index bcd7d03cde6219327f7c5c62fa3a31d3c467e329..614eb03f232cd46194c89b0f7877a40d534eabfb 100644 (file)
--- a/talk.txt
+++ b/talk.txt
@@ -300,22 +300,12 @@ If you want to push without uploading that's fine too: git-debrebase
 stitch will just make the pseudomerge for you, giving you a
 fast-forwarding branch suitable for pushing to salsa or whereever.
 
-There is one caveat I should mention: right now, if two git-debrebase
-branches diverge, it is not trivial to merge them again.  If
-git-debrebase encounters a normal `git merge' it will stop and fail.
-Sorting this out is not a trivial problem.  gbp pq sometimes handles
-this kind of situation by expecting you to merge the actual patches:
-ie, you can end up resolving merge conflicts in diffs.  The other
-tools can handle this badly too.
-
-I have ideas about how to do better at this, so watch this space.
-But, for now, avoid allowing your git-debrebase branch to diverge.
-git-debrebase will help you with that by often spotting when it is
-about to occur.
-
 ===== data model slide merge conflict failure
 
-What if you have a merge conflict during the upstream rebase ?
+More common is a different kind of merge problem.
+
+What happens if you one of your delta queue commits doesn't apply
+during the upstream rebase ?
 
 git-rebase users will have seen this kind of situation before.
 git-rebase stops at the first commit which can't be applied in
@@ -342,6 +332,27 @@ The autogenerated special breakwater merge, and changelog entry, are
 discarded, leaving you just where you were before.  You've wasted no
 effort because everything you're throwing away was machine-made.
 
+===== data model slide [5] AGAIN
+
+There is one caveat I should mention:
+
+Right now, if two git-debrebase branches diverge, it is not trivial to
+merge them again.  The data model I'm describing does not currently
+allow general merge commits.
+
+If git-debrebase encounters a normal `git merge' it will stop and
+fail.  In the general case, sorting out such a merge is not a trivial
+problem.
+
+gbp pq sometimes handles this kind of situation by expecting you to
+merge the actual patches: ie, you can end up resolving merge conflicts
+in diffs.  Other tools don't always handle this well either.
+
+I have ideas about how to do better at this, so watch this space.
+But, for now, teams should coordinate to avoid creating diverging
+git-debrebase branches.  git-debrebase will help you with that by
+often spotting when it is about to occur.
+
 ===== status and references slide
 
 git-debrebase is available in testing and stretch-backports and is in
@@ -350,7 +361,7 @@ with security updates to the Debian Xen packages.  The documentation
 is comprehensive.
 
 No doubt the user interface and documentation will improve, and new
-features will will be added, but you can start using it right away.
+features will will be added.  But you can start using it right away.
 
 The best starting point is probably the tutorial manpage
 dgit-maint-debrebase (7) (which is in the dgit package).