Junio C Hamano writes:
> Jeff King writes:
>
>> From the user's perspective, calling X "rerere" would probably be OK[1].
>> But from an implementation perspective (and to keep the existing
>> plumbing available and unchanged), it probably makes sense to call it
>> something else, and have it run
Jeff King writes:
> Hrm. That doesn't quite work, though. Because if your are the
> merge, then merging a topic to next will get an "A" that is a merge
> commit from next. But that commit will never end up in master. What's
> causing the conflict is really some "A" that is in the history between
Jeff King writes:
> From the user's perspective, calling X "rerere" would probably be OK[1].
> But from an implementation perspective (and to keep the existing
> plumbing available and unchanged), it probably makes sense to call it
> something else, and have it run both rerere and a new plumbing
On Tue, Jul 25, 2017 at 01:26:34PM -0700, Junio C Hamano wrote:
> This is not even a limitation but is outside the scope of rerere.
> Let's understand that first.
> [...]
> If we wanted to port the "merge-fix" logic, and I do wish it would
> happen some day, the update belongs to "git merge".
Loo
Junio C Hamano writes:
> To populate the database, we'd need a reverse.
> ...
> * Then the user tells Git that semantic conflicts were resolved and
>need to be recorded (just like running "git rerere" manually,
>before "git commit" automatically does it for them these days).
>This wi
Jeff King writes:
>> 1) Is this a known limitation or is there a reason rerere works in
>> this manner?
>
> Yes, it's known. Rerere works by storing a mapping of conflicted hunks
> to their resolutions. If there's no conflicted hunk, I'm not sure how
> we'd decide what to feed into the mapping to
On Tue, Jul 25, 2017 at 03:54:32PM -0400, Raman Gupta wrote:
> > That said, I'm far from an expert on how rerere works. Junio might have
> > ideas on how we could handle this better. But I do note that for
> > repeated integration runs (like we do for topics in git.git, as they get
> > merged to "
On 25/07/17 01:52 PM, Jeff King wrote:
> On Tue, Jul 25, 2017 at 11:09:55AM -0400, Raman Gupta wrote:
>
>> I had an interesting situation today: resolving a merge conflict
>> required modification in other files that were not themselves conflicting.
>>
>> I just realized that rerere does not remem
On Tue, Jul 25, 2017 at 11:09:55AM -0400, Raman Gupta wrote:
> I had an interesting situation today: resolving a merge conflict
> required modification in other files that were not themselves conflicting.
>
> I just realized that rerere does not remember any changes to these
> additional files --
I had an interesting situation today: resolving a merge conflict
required modification in other files that were not themselves conflicting.
I just realized that rerere does not remember any changes to these
additional files -- only changes to the conflicting files. This makes
the end result of rer
10 matches
Mail list logo
