From: Juliusz Chroboczek <Juliusz.Chroboczek@pps•jussieu.fr>
To: darcs-devel@darcs•net
Cc: Linus Torvalds <torvalds@osdl•org>,
Git Mailing List <git@vger•kernel.org>
Subject: Re: Darcs and git: plan of action
Date: Tue, 19 Apr 2005 02:55:05 +0200 [thread overview]
Message-ID: <7iy8bf7fh2.fsf@lanthane.pps.jussieu.fr> (raw)
In-Reply-To: <20050418122011.GA13769@abridgegame.org> (David Roundy's message of "Mon, 18 Apr 2005 08:20:21 -0400")
[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 versions (from and
to). Which is why Darcs needs to support arbitrarily formatted patch
ids -- a patch originating from git will be identified by a pair of
git hashes.
Obviously, we'll need to think harder when pushing from darcs into git
(we'll need to preserve the Darcs patch id somehow), but it's premature
to worry about that right now.
>> 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 with this,
Why?
>> 3. allow a patch to have multiple IDs; if the IDs associated to two
>> patches are not disjoint, then the patches are the same patch.
>
> This I find a bit confusing. So a patch can have two IDs, presumably
> something like a "darcs ID" and a "git ID"? I can see that this might
> simplify some things, but am not sure how it would work. The IDs would
> have to have a hierarchy, so that you wouldn't ever end up with the "same"
> patch having disjoint IDs in two cases.
It's a case of ``don't do that''.
Suppose I record a patch in Darcs; it gets a Darcs id. I push it into
git, at which point it gets a git id, whether we want it to or not.
What do we do when we pull that patch back into darcs?
Either we arbitrarily discard one of the ids (which one?), or we keep
both. If there's more pulling/pushing going on on the git side, we
definitely need to keep both.
> Here's where I think I'd differ.
Same to you ;-)
> I think when dealing with git (and probably also with *any* other
> SCM (arch being a possible exception), we need to consider the
> exchange medium to be not a patch, but a tag.
We're thinking in opposite directions -- you're thinking of the alien
versions as integrals of Darcs patches, I'm thinking of Darcs patches
as derivatives of alien versions.
You: alien version = Darcs tag
Me: Darcs patch = pair of successive alien versions
My gut instinct is that the second model can be made to work almost
seamlessly, unlike the first one. But that's just a guess.
> if we want long-term stability we might need to mummify a variant of
> the diff algorithm that we agree not to change,
Good point, noted.
> 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).
Happily, it's premature to worry about that, too.
Juliusz
next prev parent reply other threads:[~2005-04-19 0:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <7ivf6lm594.fsf@lanthane.pps.jussieu.fr>
2005-04-18 12:20 ` Darcs and git: plan of action 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-18 18:35 ` [darcs-devel] " Ray Lee
2005-04-19 0:55 ` Juliusz Chroboczek [this message]
2005-04-19 1:43 ` Ray Lee
2005-04-19 8:22 ` Juliusz Chroboczek
2005-04-20 1:22 ` Ray Lee
2005-04-19 11:04 ` David Roundy
2005-04-19 12:20 ` Juliusz Chroboczek
2005-04-19 12:25 ` [darcs-devel] " Petr Baudis
2005-04-20 11:18 ` David Roundy
2005-04-20 11:29 ` David Roundy
2005-04-18 21:04 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:40 ` Ray Lee
2005-04-19 23:00 ` Tupshin Harper
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
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=7iy8bf7fh2.fsf@lanthane.pps.jussieu.fr \
--to=juliusz.chroboczek@pps$(echo .)jussieu.fr \
--cc=darcs-devel@darcs$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=torvalds@osdl$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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