Re: [PATCH v8 0/8] refs: add support for transactional symref updates

[Junio C Hamano <gitster@pobox.com>]

Karthik Nayak <karthik.188@gmail.com> writes:

> Changes since v7:
> * I had rebased v7 on next. I've rebased v8 on master. That's the only difference
> between the two versions.

I've applied them to the same base as used to queue the previous
round, which I think is "436d4e5b14 The seventeenth batch".  It went
without conflicts, and tests fine in isolation.  I'll see if it plays
well with other topics in 'seen' later in the day but not now.

Thanks.

> Junio, this might cause conflicts when merging, I think you resolved them for
> v6 and hope its the same now. Let me know if I can help otherwise somehow. 

The easiest for both of us would be to do this:

 (1) Build on whatever base you want, and format-patch the series.
     If you are doing "rebase -i" in-place to update from the
     previous round, this will reuse the previous base so (2) and
     (3) may become trivial.

 (2) Find the base of where the last round was queued, something like

     $ mine='kn/ref-transaction-symref'
     $ git checkout "origin/seen^{/^Merge branch '$mine'}...master"

 (3) Apply your format-patch result.  There are three cases

     (3)-1. Things apply cleanly and tests fine.  Go to (4).

     (3)-2. Things apply cleanly but does not build or test fails,
	    or things do not apply cleanly.

     In the latter case, you have textual or semantic conflicts
     coming from the difference between the old base and the base
     you used to build in (1).  Identify what caused the breakages
     (e.g., a topic or two may have merged since the base used by
     (2) until the base used by (1)).

     Check out the latest 'origin/master' (which may be newer than
     the base used by (2)), "merge --no-ff" the topics you newly
     depend on in there, and use the result of the merge(s) as the
     base, rebuild the series and test again.  Run format-patch from
     the last such merges to the tip of your topic.  If you did

     $ git checkout origin/master
     $ git merge --no-ff --into kn/ref-transaction-symref fo/obar
     $ git merge --no-ff --into kn/ref-transaction-symref ba/zqux
     ... rebuild the topic ...

     Then you'd just format your topic above these "preparing the
     ground" merges, e.g.

     $ git format-patch "HEAD^{/^Merge branch 'ba/zqux'}"..HEAD

     Do not forget to write in the cover letter you did this,
     including the topics you have in your base on top of 'master'.
     Then go to (4).

 (4) Make a trial merge of your topic into 'next' and 'seen', e.g.

     $ git checkout --detach 'origin/seen' &&
       git revert -m 1 <the merge of the previous iteration into seen> &&
       git merge kn/ref-transaction-symref

     The "revert" is needed if the previous iteration of your topic
     is already in 'seen' (like in this case).  You could choose to
     rebuild master..origin/seen from scratch while excluding your
     previous iteration, which may emulate what happens on my end
     more closely.

     This trial merge may conflict.  It is primarily to see what
     conflicts _other_ topics may have with your topic.  In other
     words, you do not have to depend on to make your topic work on
     'master'.  It may become the job of the other topic owners to
     resolve conflicts if your topic goes to 'next' before theirs.

     Make a note on what conflict you saw in the cover letter.  You
     do not necessarily have to resolve them, but it would be a good
     opportunity to learn what others are doing in an related area.

     $ git checkout --detach 'origin/next' &&
       git merge kn/ref-transaction-symref

     This is to see what conflicts your topic has with other topics
     that are already cooking.  This should not conflict if (3)-2
     prepared a base on top of updated master plus dependent topics
     taken from 'next'.  Unless the context is severe (one way to
     tell is try the same trial merge with your old iteration, which
     may conflict in a similar way), expect that it will be handled
     on my end (if it gets unmanageable, I'll ask to rebase when I
     receive your patches).

Something like the above should be added to the SubmittingPatches
document (or its successor to cover more advanced topics, perhaps).

Thanks.