Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

[Junio C Hamano]

Johannes Schindelin  writes:

> I do not need cc/apply-am at all, it turns out, but my patch series has a
> minor conflict with 'jc/renormalize-merge-kill-safer-crlf'.
>
> Since you indicated that you want to cook that branch a bit in 'next'
> first, I will rebase to master+bc/cocci+js/am-call-theirs-theirs and
> re-submit.

Thanks.  I suspect the renomalization would graduate earlier than
the topic in question, but leaving dependency to the minimum and
have rerere take care of minor conflicts has proved to be a better
approach in general over time; the base you chose above sounds
appropriate.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

[Johannes Schindelin]

Hi Junio,

On Tue, 19 Jul 2016, Johannes Schindelin wrote:

> On Mon, 18 Jul 2016, Junio C Hamano wrote:
> 
> > Junio C Hamano  writes:
> > 
> > You can assume that I'll merge bc/cocci and
> > js/am-call-theirs-theirs-in-fallback-3way to 'master' during that time,
> > so an appropriate base to use would be the result of
> > 
> > git checkout master^0
> > git merge bc/cocci
> > git merge js/am-call-theirs-theirs-in-fallback-3way
> > git merge cc/apply-am
> > 
> > if you want a semi-solid base to rebuild am-3-merge-recursive-direct
> > on.

I do not need cc/apply-am at all, it turns out, but my patch series has a
minor conflict with 'jc/renormalize-merge-kill-safer-crlf'.

Since you indicated that you want to cook that branch a bit in 'next'
first, I will rebase to master+bc/cocci+js/am-call-theirs-theirs and
re-submit.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

[Johannes Schindelin]

Hi Junio,

On Mon, 18 Jul 2016, Junio C Hamano wrote:

> Junio C Hamano  writes:
> 
> > Johannes Schindelin  writes:
> >
> >> The two topics that are in 'pu' and conflict with this series are
> >> 'jh/clean-smudge-annex' and 'bc/cocci'.
> >>
> >> It also conflicted with 'va/i18n-even-more', but that one was merged to
> >> 'master'.
> >>
> >> Now, I think it would be okay to wait for 'bc/cocci' to go to 'master'
> >> before integrating the 'am-3-merge-recursive-direct' branch, but I would
> >> want to avoid waiting for 'jh/clean-smudge-annex'.
> 
> Nothing seems to be happening on jh/clean-smudge-annex front, so
> unless we hear otherwise from Joey in the coming couple of days,
> let's get js/am-3-merge-recursive-direct untangled from its
> dependencies and get it into a shape to hit 'next'.

Okay, I will rebase and re-submit.

> You can assume that I'll merge bc/cocci and
> js/am-call-theirs-theirs-in-fallback-3way to 'master' during that time,
> so an appropriate base to use would be the result of
> 
> git checkout master^0
> git merge bc/cocci
> git merge js/am-call-theirs-theirs-in-fallback-3way
> git merge cc/apply-am
> 
> if you want a semi-solid base to rebuild am-3-merge-recursive-direct
> on.

Okay. The way my `mail-patch-series.sh` script works, however, is that it
infers the base commit by testing which tip among pu, next and master is
the most appropriate.

So I guess I will have to hack it up a bit to allow basing my patch series
on something custom.

> I am not 100% sure about the doneness of cc/apply-am yet, though but it
> could be that am-3-merge-recursive-direct does not have to depend on it
> at all.  You'd know better than I do ;-)

I agree on the doneness of cc/apply-am (as you know, I tried to help it
along but my comments had an adverse effect).

And no: nothing in my entire rebase--helper patches relies on cc/apply-am
(I do not even believe that anything conflicts with it, either).

> After that, I'll see if the conflict resolution is manageable when
> remerging jh/clean-smudge-annex to 'pu', and if it is not, I'll worry
> about it at that point.

I can help with that, too.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

[Junio C Hamano]

Junio C Hamano  writes:

> Johannes Schindelin  writes:
>
>> The two topics that are in 'pu' and conflict with this series are
>> 'jh/clean-smudge-annex' and 'bc/cocci'.
>>
>> It also conflicted with 'va/i18n-even-more', but that one was merged to
>> 'master'.
>>
>> Now, I think it would be okay to wait for 'bc/cocci' to go to 'master'
>> before integrating the 'am-3-merge-recursive-direct' branch, but I would
>> want to avoid waiting for 'jh/clean-smudge-annex'.

Nothing seems to be happening on jh/clean-smudge-annex front, so
unless we hear otherwise from Joey in the coming couple of days,
let's get js/am-3-merge-recursive-direct untangled from its
dependencies and get it into a shape to hit 'next'.  You can assume
that I'll merge bc/cocci and js/am-call-theirs-theirs-in-fallback-3way
to 'master' during that time, so an appropriate base to use would be
the result of

git checkout master^0
git merge bc/cocci
git merge js/am-call-theirs-theirs-in-fallback-3way
git merge cc/apply-am

if you want a semi-solid base to rebuild am-3-merge-recursive-direct
on.  I am not 100% sure about the doneness of cc/apply-am yet,
though but it could be that am-3-merge-recursive-direct does not
have to depend on it at all.  You'd know better than I do ;-)

After that, I'll see if the conflict resolution is manageable when
remerging jh/clean-smudge-annex to 'pu', and if it is not, I'll
worry about it at that point.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

[Junio C Hamano]

Johannes Schindelin  writes:

> The two topics that are in 'pu' and conflict with this series are
> 'jh/clean-smudge-annex' and 'bc/cocci'.
>
> It also conflicted with 'va/i18n-even-more', but that one was merged to
> 'master'.
>
> Now, I think it would be okay to wait for 'bc/cocci' to go to 'master'
> before integrating the 'am-3-merge-recursive-direct' branch, but I would
> want to avoid waiting for 'jh/clean-smudge-annex'.
>
> Do you concur? If so, I will rebase onto 'master' as soon as 'bc/cocci'
> lands in there.

I do not have a strong preference myself.  As you are not proposing
to eject jh/clean-smudge-annex from my tree, I'd have to resolve the
conflicts when the second topic is merged after one topic, whichever
happens to be more ready.  IOW, such a rebase adds to my workload.

Like it or not, it is normal for different topics to want to touch
the overlapping area or one topic to invalidate an assumption the
other topic is based on, and working well together does not have to
mean leaving the conflict resolution to the sole responsibility of
the integrator.  A clean way forward may be for everybody involved
(and I see you forgot to add Joey to this thread) to agree that this
topic is more ready than jh/clean-smudge-annex and you and Joey to
work together to rebase jh/clean-smudge-annex on top of this topic
(or possibly the other way around), making him wait for you.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

[Johannes Schindelin]

Hi Junio,

On Tue, 12 Jul 2016, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > This is the second iteration of the long-awaited re-roll of the attempt to
> > avoid spawning merge-recursive from the builtin am and use merge_recursive()
> > directly instead.
> 
> This is actually the third iteration.

It is.

> I am trying to tease dependencies apart and apply this on a more
> reasonable base than a commit that happened to be at 'pu' on one
> day, but this would probably take some time, and I may give up
> merging it anywhere for today's integration cycle.  We'll see.

The two topics that are in 'pu' and conflict with this series are
'jh/clean-smudge-annex' and 'bc/cocci'.

It also conflicted with 'va/i18n-even-more', but that one was merged to
'master'.

Now, I think it would be okay to wait for 'bc/cocci' to go to 'master'
before integrating the 'am-3-merge-recursive-direct' branch, but I would
want to avoid waiting for 'jh/clean-smudge-annex'.

Do you concur? If so, I will rebase onto 'master' as soon as 'bc/cocci'
lands in there.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

[Junio C Hamano]

Johannes Schindelin  writes:

> This is the second iteration of the long-awaited re-roll of the attempt to
> avoid spawning merge-recursive from the builtin am and use merge_recursive()
> directly instead.

This is actually the third iteration.

I am trying to tease dependencies apart and apply this on a more
reasonable base than a commit that happened to be at 'pu' on one
day, but this would probably take some time, and I may give up
merging it anywhere for today's integration cycle.  We'll see.





--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html