From: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Finn Arne Gangstad <finnag@pvv.org>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
Date: Fri, 25 Jun 2010 21:43:57 +0200 [thread overview]
Message-ID: <CFE3DCC1-E80A-4EF3-964B-E791D3224F06@gmail.com> (raw)
In-Reply-To: <7vtyosnj23.fsf@alter.siamese.dyndns.org>
On 25. juni 2010, at 00.48, Junio C Hamano wrote:
> Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> writes:
>
>> Hm. Isn't that already a requirement? If a clean filter doesn't clean
>> to something normalized, simply touching a file could result in spurious
>> differences (much like pre-safe-autocrlf autocrlf). I could well be
>> missing something here, though.
>
> A natural expectation would be that g2w-then-w2g is an identity function,
> I think. But the "feature" under discussion in this thread depends on
> that g2w-then-w2g is _not_ a noop (otherwise it wouldn't do us any good).
Well, it assumes that g2w does not smudge already smudged data (or that w2g can clean up after double smudging), but when the assumption fails you end up with the same merge conflict you would get without this series. Is it important that _all_ filters support merging?
> IOW, we are suggesting authors of clean/smudge to make their g2w-then-w2g
> perform more than just a round-trip but actively _clean things up_, aren't
> we? I don't think we have documented that suggestion, and I actually
> think we might even have said that g2w-then-w2g should be a no-op
> somewhere in the documentation.
I think it's worth documenting that a well-written ("normalizing", as Finn Arne said) filter allows automatic merging of filtered and unfiltered data. I'll see what I can come up with.
--
Eyvind
next prev parent reply other threads:[~2010-06-25 19:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-23 22:09 What's cooking in git.git (Jun 2010, #04; Wed, 23) Junio C Hamano
[not found] ` <7veifxe63j.fsf@alter.siamese.dyndns.org>
2010-06-23 22:54 ` [PATCH] bash completion: Support "divergence from upstream" messages in __git_ps1 Shawn O. Pearce
2010-06-23 23:21 ` What's cooking in git.git (Jun 2010, #04; Wed, 23) Ævar Arnfjörð Bjarmason
2010-06-24 0:44 ` Nazri Ramliy
2010-06-24 3:46 ` Tay Ray Chuan
2010-06-24 11:17 ` Finn Arne Gangstad
2010-06-24 11:42 ` Johannes Sixt
2010-06-24 11:58 ` Finn Arne Gangstad
2010-06-24 12:23 ` Eyvind Bernhardsen
2010-06-24 20:21 ` Junio C Hamano
2010-06-24 20:51 ` Eyvind Bernhardsen
2010-06-24 22:48 ` Junio C Hamano
2010-06-25 8:43 ` Finn Arne Gangstad
2010-06-25 19:43 ` Eyvind Bernhardsen [this message]
2010-06-25 21:17 ` Junio C Hamano
2010-06-25 6:02 ` Johannes Sixt
2010-06-25 7:46 ` Finn Arne Gangstad
2010-06-24 14:48 ` Johannes Sixt
2010-06-24 15:33 ` git log --objects Holger Hellmuth
2010-06-25 10:06 ` Santi Béjar
2010-06-24 15:41 ` What's cooking in git.git (Jun 2010, #04; Wed, 23) Clément Poulain
2010-06-25 2:27 ` Christian Couder
2010-06-25 10:30 ` Ævar Arnfjörð Bjarmason
2010-06-25 13:43 ` Michael J Gruber
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=CFE3DCC1-E80A-4EF3-964B-E791D3224F06@gmail.com \
--to=eyvind.bernhardsen@gmail.com \
--cc=finnag@pvv.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).