From: Tupshin Harper <tupshin@tupshin.com>
To: Ray Lee <ray-lk@madrabbit.org>
Cc: git@vger.kernel.org, Kevin Smith <yarcs@qualitycode.com>,
darcs-devel@darcs.net
Subject: Re: Darcs and git: plan of action
Date: Tue, 19 Apr 2005 16:00:37 -0700 [thread overview]
Message-ID: <42658D95.7020404@tupshin.com> (raw)
In-Reply-To: <1113950442.29444.31.camel@orca.madrabbit.org>
Ray Lee wrote:
>Here's where we disagree. If you checkpoint your tree before the
>replace, and immediately after, the only differences in the
>source-controlled files would be due to the replace.
>
This is assuming that you only have one replace and no other operations
recorded in the patch. If you have multiple replaces or a replace and a
traditional diff recorded in the same patch, then this is not true.
> And since the
>language of the file is known (and thereby the tokenization -- it *is*
>well-defined), then a tokenizer that compares the before and after trees
>(for just the files that changed, obviously), can discover what you did,
>and promote the mere ASCII diff into a token-replace diff. (The same
>sort of idea could be done for reindention, I'd hope.)
>
>
See above for one set of limitations on this. A more fundamental problem
comes back to intent. If I have a file "foo" before:
a1
a2
and after:
b1
b2
is that a "replace [_a-zA-Z0-9] a b foo" patch, or is that a
-a1
-a2
+b1
+b2
patch? Note that this comes down to heuristics, and no matter what you
use, you will be wrong sometimes, *and* the choice that is made can
substantively affect the contents of the repository after additional
patches are applied.
>We agree on everything except that it's provable that one can discover a
>replace operation, given a before and after tree.
>
>
It's provable that you can not.
-Tupshin
next prev parent reply other threads:[~2005-04-19 22:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-18 21:04 [darcs-devel] Darcs and git: plan of action linux
2005-04-19 0:07 ` Ray Lee
2005-04-19 1:05 ` Kevin Smith
2005-04-19 1:42 ` Ray Lee
2005-04-19 2:05 ` Kevin Smith
2005-04-19 22:08 ` Patrick McFarland
2005-04-19 22:40 ` Ray Lee
2005-04-19 23:00 ` Tupshin Harper [this message]
2005-04-19 23:21 ` Ray Lee
2005-04-19 23:38 ` Tupshin Harper
2005-04-19 23:03 ` [darcs-devel] " Kevin Smith
2005-04-19 23:06 ` Ray Lee
2005-04-19 23:32 ` Tupshin Harper
2005-04-20 1:11 ` [darcs-devel] " Ray Lee
2005-04-20 7:52 ` Juliusz Chroboczek
2005-04-20 11:55 ` David Roundy
2005-04-20 17:11 ` Ralph Corderoy
2005-04-19 11:05 ` David Roundy
[not found] <7ivf6lm594.fsf@lanthane.pps.jussieu.fr>
2005-04-18 12:20 ` David Roundy
2005-04-18 15:38 ` Linus Torvalds
2005-04-19 10:42 ` [darcs-devel] " David Roundy
2005-04-19 14:55 ` Linus Torvalds
2005-04-19 16:33 ` [darcs-devel] " Tupshin Harper
2005-04-19 16:49 ` Linus Torvalds
2005-04-20 11:14 ` David Roundy
2005-04-19 0:55 ` Juliusz Chroboczek
2005-04-19 11:04 ` [darcs-devel] " David Roundy
2005-04-19 12:20 ` Juliusz Chroboczek
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=42658D95.7020404@tupshin.com \
--to=tupshin@tupshin.com \
--cc=darcs-devel@darcs.net \
--cc=git@vger.kernel.org \
--cc=ray-lk@madrabbit.org \
--cc=yarcs@qualitycode.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.