From: Johannes Sixt <j6t@kdbg.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 9/9] rerere forget path: forget recorded resolution
Date: Wed, 06 Jan 2010 09:55:21 +0100 [thread overview]
Message-ID: <4B444FF9.1000004@kdbg.org> (raw)
In-Reply-To: <7v4on0oxcs.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j6t@kdbg.org> writes:
>> When you simply call ll_merge(), will it obey any merge drivers that
>> are defined in .gitattributes? Do we care about them?
>>
>> I already had an implementation of "rerere forget" before you
>> presented this solution, but it relies on that the user calls
>> "checkout --conflict=merge" first. One reason (besides its simplicity)
>> was that it does not have to care how the merge is computed.
>
> Doesn't "checkout --conflict=merge" use the same ll_merge() machinery?
It does, without setting up .gitattributes, either (IIUC), which is a bug IMO.
That said, I consider your solution superior because it works without
depending on conflict markers in the file in the worktree. Nevertheless,
we should think about whether merge drivers of .gitattributes should be
obeyed. I think they should: For example, a specialized XML merge driver
could leave conflicts that are different from those that merge-recursive
generates.
-- Hannes
next prev parent reply other threads:[~2010-01-06 8:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-21 18:58 [PATCH/RFC 0/3] git rerere unresolve file Johannes Sixt
2009-11-21 19:00 ` [PATCH/RFC 1/3] rerere: keep a list of resolved files in MERGE_RR Johannes Sixt
2009-11-21 19:01 ` [PATCH/RFC 2/3] rerere: make recording of the preimage reusable Johannes Sixt
2009-11-21 19:02 ` [PATCH/RFC 3/3] git rerere unresolve file Johannes Sixt
2009-11-22 2:53 ` [PATCH/RFC 0/3] " Junio C Hamano
2009-11-22 14:19 ` Johannes Sixt
2009-11-24 23:40 ` Nanako Shiraishi
2009-12-29 21:42 ` [PATCH 0/9] Undoing conflict resolution Junio C Hamano
2009-12-29 21:42 ` [PATCH 1/9] builtin-merge.c: use standard active_cache macros Junio C Hamano
2009-12-29 21:42 ` [PATCH 2/9] resolve-undo: record resolved conflicts in a new index extension section Junio C Hamano
2009-12-29 21:42 ` [PATCH 3/9] resolve-undo: basic tests Junio C Hamano
2009-12-29 21:42 ` [PATCH 4/9] resolve-undo: allow plumbing to clear the information Junio C Hamano
2009-12-29 21:42 ` [PATCH 5/9] resolve-undo: "checkout -m path" uses resolve-undo information Junio C Hamano
2009-12-29 21:42 ` [PATCH 6/9] resolve-undo: teach "update-index --unresolve" to use resolve-undo info Junio C Hamano
2009-12-29 21:42 ` [PATCH 7/9] rerere: remove silly 1024-byte line limit Junio C Hamano
2009-12-29 21:42 ` [PATCH 8/9] rerere: refactor rerere logic to make it independent from I/O Junio C Hamano
2009-12-29 21:42 ` [PATCH 9/9] rerere forget path: forget recorded resolution Junio C Hamano
2010-01-05 21:25 ` Johannes Sixt
2010-01-06 1:06 ` Junio C Hamano
2010-01-06 8:55 ` Johannes Sixt [this message]
2010-01-06 16:58 ` Junio C Hamano
2010-01-06 21:59 ` Junio C Hamano
2010-01-08 21:55 ` Johannes Sixt
2010-01-08 23:20 ` Junio C Hamano
2010-01-11 1:58 ` Junio C Hamano
2010-01-11 19:22 ` Johannes Sixt
2010-01-11 20:05 ` Junio C Hamano
2010-01-11 21:05 ` Johannes Sixt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B444FF9.1000004@kdbg.org \
--to=j6t@kdbg.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).