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

> 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.