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 respond to
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 has a
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
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
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
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.
Hell
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 comfortable
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
foo
[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 bytes
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 having
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
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 project
(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].
No, it can'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
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 without
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 recently,
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 it has
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. Of
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 rules,
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 as rules, not
20 matches
Mail list logo
