Hi Ray,
> Give me a case where assuming it's a replace will do the wrong thing,
> for C code, where it's a variable or function name.
How about two patches.
1. s/foo/bar/ throughout file because foo() has been decided upon
as the name of a new globally visible forthcoming function but
On Tue, Apr 19, 2005 at 06:11:43PM -0700, Ray Lee wrote:
> > second patch:
> > replace ./hello.c [A-Za-z_0-9] world universe
>
> Aha! Okay, I now see at least part of issue: we're using different
> definitions of 'token.' Yours is quite sensible, in that it matches the
> darcs syntax. However, I'm
On Tue, Apr 19, 2005 at 02:20:55PM +0200, Juliusz Chroboczek wrote:
> [Removing Linus from CC, keeping the Git list -- or should we remove it?]
I think leaving much of this on git would be appropriate, since there are
issues of how to relate to git that should be relevant.
> > If we do it right (
On Tue, Apr 19, 2005 at 02:25:18PM +0200, Petr Baudis wrote:
> Dear diary, on Tue, Apr 19, 2005 at 02:20:55PM CEST, I got a letter
> where Juliusz Chroboczek <[EMAIL PROTECTED]> told me that...
> > > The problem is that there is no sequence of alien versions that one
> > > can differentiate. Git h
On Tue, Apr 19, 2005 at 09:49:12AM -0700, Linus Torvalds wrote:
> On Tue, 19 Apr 2005, Tupshin Harper wrote:
> > I suspect that any use of wildcards in a new format would be impossible
> > for darcs since it wouldn't allow darcs to construct dependencies,
> > though I'll leave it to david to respon
> We're talking about interoperating with a Git repository here,
> right? Even if we got the metadata in there, doesn't Git have to
> understand a replace patch for things to work out?
> 0. All three are in sync to begin with.
> 1. CC creates a token-replace patch, sends the changes in normal hu
> However, I'm claiming a token is defined by the file's language, and
> that a replace patch on anything but a token as per those language
> standards is a silly thing.
Please recall the context of this discussion: getting Darcs to grok
git repositories.
You are arguing that it should be possibl
On Tue, 2005-04-19 at 10:22 +0200, Juliusz Chroboczek wrote:
> > > Aye, that will require some metadata on the git side (the hack,
> > > suggested by Linus, of using git hashes to notice moves won't work).
>
> > So, why won't it work?
>
> Because two files can legitimately have identical contents
Thanks for your patience.
On Tue, 2005-04-19 at 16:32 -0700, Tupshin Harper wrote:
> >Give me a case where assuming it's a replace will do the wrong thing,
> >for C code, where it's a variable or function name.
> try this:
> initial patch creates hello.c
> #include
>
> int main(int argc, char *
Ray Lee wrote:
it allows regular expressions for the match and replace, which means
multiple unique tokens could change atomically. (Does anyone actually
*use* regexes? Sounds like a cannon that'd be hard to aim.)
Yes, and replace patches need to be used very carefully.
Regardless, I only care a
Ray Lee wrote:
I'm still not communicating well.
Give me a case where assuming it's a replace will do the wrong thing,
for C code, where it's a variable or function name.
Ray
-
I think you are communicating fine, but not fully understanding darcs.
try this:
initial patch creates hello.c
#include
i
On Tue, 2005-04-19 at 16:00 -0700, Tupshin Harper wrote:
> 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 onl
On Tue, 2005-04-19 at 19:03 -0400, Kevin Smith wrote:
> Pop quiz:
> Here is revision 1 of my file:
> abcde
>
> Here is revision 2:
> wow
> Now, did I do that with a darcs replace, or just by typing?
I'm still not communicating well.
Give me a case where assuming it's a replace will do t
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 hav
Ray Lee wrote:
> On Mon, 2005-04-18 at 22:05 -0400, Kevin Smith wrote:
>
>>Notice that just by looking at my diffs, you can't tell that I used a
>>replace operation.
>
>
> Here's where we disagree. If you checkpoint your tree before the
> replace, and immediately after, the only differences in t
(Sorry for the delayed reply -- I'm living on tape delay for a bit.)
On Mon, 2005-04-18 at 22:05 -0400, Kevin Smith wrote:
> The other is "replace very instace of identifier `foo` with
> identifier`bar`".
> >>>
> >>>That could be derived, however, by a particularly smart parser [1].
> >>
On Monday 18 April 2005 10:05 pm, Kevin Smith wrote:
> The big feature of a darcs replace patch is that it works forward and
> backward in time. Let me try to come up with an example that can help
> explain it. Hopefully I'll get it right. Let's start with a file like
> this that exists in a projec
On Tue, 19 Apr 2005, Tupshin Harper wrote:
>
> I suspect that any use of wildcards in a new format would be impossible
> for darcs since it wouldn't allow darcs to construct dependencies,
> though I'll leave it to david to respond to that.
Note that git _does_ very efficiently (and I mean _ve
Linus Torvalds wrote:
(In other words: if it looks like something a careful human _could_ have
written, it's certainly ok. But if it looks like something a careful human
would have used a script to generate 40 entries of, it's bad).
Linus
This is the way that darcs would currently represent a
On Tue, 19 Apr 2005, David Roundy wrote:
>
> Would a small amount of human-readable change information be acceptable in
> the free-form comment area? In the rename thread I got the impression this
> would be okay for renames. For example,
>
> rename foo bar
Sure. That's human-readable and mea
Dear diary, on Tue, Apr 19, 2005 at 02:20:55PM CEST, I got a letter
where Juliusz Chroboczek <[EMAIL PROTECTED]> told me that...
> > The problem is that there is no sequence of alien versions that one can
> > differentiate. Git has a branched history, with each version that follows
> > a merge hav
[Removing Linus from CC, keeping the Git list -- or should we remove it?]
> I'm not clear why it would be necesary, and it takes the only immutable
> piece of information regarding a patch, and makes it variable.
Er... I'm not suggesting to make it variable, just to make it an
opaque blob of byte
On Mon, Apr 18, 2005 at 06:42:11PM -0700, Ray Lee wrote:
> On Mon, 2005-04-18 at 21:05 -0400, Kevin Smith wrote:
> > You could guess, but that's not good enough for darcs to be able to
> > reliably commute the patches later.
>
> Who said anything about guessing? If a user replaces all instances of
On Tue, Apr 19, 2005 at 02:55:05AM +0200, Juliusz Chroboczek wrote:
> [Using git as a backend for Darcs.]
...
> >> 1. remove the assumption that patch IDs have a fixed format. Patch
> >> IDs should be opaque blobs of binary data that Darcs only compares
> >> for equality.
>
> > I'm not really
On Mon, Apr 18, 2005 at 08:38:25AM -0700, Linus Torvalds wrote:
> On Mon, 18 Apr 2005, David Roundy wrote:
> > In particular, it would make life (that is, life interacting back
> > and forth with git) easier if we were to embed darcs patches in their
> > entirety in the git comment block.
>
>
> > Aye, that will require some metadata on the git side (the hack,
> > suggested by Linus, of using git hashes to notice moves won't work).
> So, why won't it work?
Because two files can legitimately have identical contents without
being ``the same'' file from the VC system's point of view.
In
Ray Lee wrote:
> On Mon, 2005-04-18 at 21:05 -0400, Kevin Smith wrote:
>
The other is "replace very instace of identifier `foo` with
identifier`bar`".
>>>
>>>That could be derived, however, by a particularly smart parser [1].
>>
>>No, it can't. Seriously. A darcs replace patch is encoded
On Tue, 2005-04-19 at 02:55 +0200, Juliusz Chroboczek wrote:
> > But avoiding "mv" patches would be downright silly.
>
> Aye, that will require some metadata on the git side (the hack,
> suggested by Linus, of using git hashes to notice moves won't work).
Okay, I'm coming to believe I missed some
On Mon, 2005-04-18 at 21:05 -0400, Kevin Smith wrote:
> >>The other is "replace very instace of identifier `foo` with
> >>identifier`bar`".
> > That could be derived, however, by a particularly smart parser [1].
>
> No, it can't. Seriously. A darcs replace patch is encoded as rules, not
> effects
Ray Lee wrote:
> On Mon, 2005-04-18 at 21:04 +, [EMAIL PROTECTED] wrote:
>
>>The other is "replace very instace of identifier `foo` with identifier`bar`".
>
>
> That could be derived, however, by a particularly smart parser [1].
No, it can't. Seriously. A darcs replace patch is encoded as r
[Using git as a backend for Darcs.]
> The problem I have with this is that "other" repository formats (e.g. git)
> store "tree versions", not "changes", and I think it would be fragile to
> try to store "changes" (in the darcs sense) in them.
Not really; a Darcs patch is just a pair of two git ve
On Mon, 2005-04-18 at 21:04 +, [EMAIL PROTECTED] wrote:
> The other is "replace very instace of identifier `foo` with identifier`bar`".
That could be derived, however, by a particularly smart parser [1].
Alternately, that itself could be embedded in the comment for patches
sourced from darcs.
> Hell no.
>
> The commit _does_ specify the patch uniquely and exactly, so I really
> don't see the point. You can always get the patch by just doing a
>
> git diff $parent_tree $thistree
>
> so putting the patch in the comment is not an option.
Er... no.
One of darcs' big points is that
On Mon, 2005-04-18 at 08:20 -0400, David Roundy wrote:
> Putting darcs patches *into* git is more complicated, since we'll want to
> get them back again without modification. Normal "hunk" patches would be
> no problem, provided we never change our diff algorithm (which has been
> discussed recent
On Mon, 18 Apr 2005, David Roundy wrote:
>
> I'm cc'ing you on this email, since Juliusz had some interesting ideas as
> to how darcs could interact with git, which then gave me an idea concerning
> which I'd like feedback from you. In particular, it would make life (that
> is, life interacting
Linus and gittish people,
I'm cc'ing you on this email, since Juliusz had some interesting ideas as
to how darcs could interact with git, which then gave me an idea concerning
which I'd like feedback from you. In particular, it would make life (that
is, life interacting back and forth with git) e
36 matches
Mail list logo
