Junio C Hamano <gitster@xxxxxxxxx> writes:
> Karthik Nayak <karthik.188@xxxxxxxxx> 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"
>
I find the '...' always so confusing, I would say suggesting to use
'git-merge-base' would be much nicer here.
> (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
For my own understanding, even if we use '--ff' the end result should be
the same, but using '--no-ff' would ensure that the changes and
conflicts are isolated to the merge commit, right?
> 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 ...
>
I guess you mean '--into-name' here? I would skip mentioning this since
it doesn't have any real effect and is perhaps confusing.
> 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.
The rest of this looks good, I'll cleanup add the appropriate syntax,
merge in your patches [1] and send something soon!
[1]: https://lore.kernel.org/all/20240510165526.1412338-1-gitster@xxxxxxxxx/#t
Attachment:
signature.asc
Description: PGP signature
