Re: [darcs-users] currently preferred way to import history from Git
Ivan Zakharyaschev wrote: 2015-01-22 13:16 UTC+03:00, Ivan Zakharyaschev i...@altlinux.org: Actually, after I make the transition to darcs, I'm thinking about a workflow with a reduced number of branches (no intersection branch AB), so I won't need a working darcs directory for AB. Does it make sense? Say, A is a feature I'm working on, and B is some implementation aspect. (In Git, I had to have the AB branch to avoid the hassle of cherry-picking a new patch from either A and B, and making sure that it is clear from the history that there is a single patch which is relevant for both A and B.) I want to add a clarification about my annoyance with Git: if I have a sequence of such A1, A2, ... branches, and B1, B2, B3, ... with the idea that A1 is a subset of A2, and so on, and B1 is a subset of B2, and so on, then it is quite tiresome to maintain the history graph clean: after I add a patch to the intersection of A1 and B1 (A1B1), I have to rebase the set of changes A1B1..A1 onto the new state of A1B1, and then A1..A2 onto the new state of A1, and so on (you get the idea). What is annoying is that I can't postpone this procedure for later, because a partially rebased history with many branches looks weird: some heads are updated, but some are left attached to the old tree, and you don't get the idea of each branch being a superset of some other one. With darcs, it would at least seem not to be so weird because you are not forced to think about the non-rebased branches as long independent branches, but rather a set merely lacking just a few new patches. Hi Ivan I can totally relate to that. This is one of the main reasons I love Darcs: the set of changes model is so much more flexible than the usual history of revisions model. The downside is that sometimes it can be too flexible: recovering an earlier state can be tricky in Darcs, unless you already have a tag or the state is only a few patches back. Anyway, I am glad to see that there are still people preferring -- and even willing to switch to -- Darcs because of technical reasons like the more flexible repository model, as opposed to those converting to git mostly because that's what everyone else uses. So, welcome aboard Darcs, next stop will be at Alpha Centauri... ;-) Cheers Ben -- Make it so they have to reboot after every typo. -- Scott Adams ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] currently preferred way to import history from Git
Hi,
Fri, 23 Jan 2015 17:16 +0100, Ben Franksen ben.frank...@online.de:
Ivan Zakharyaschev wrote:
2015-01-22 9:53 UTC+03:00, Ganesh Sittampalam gan...@earth.li:
'darcs convert' is currently supported.
So, I believe 'darcs convert --import' doesn't have the notion of Git
branches, does it? (At least, there are no examples of using 'darcs
convert --import' on the wiki at all, so I can only guess.)
Then, I believe, I should proceed as follows if I want to import Git
branches AB, A, B from repo repo, such that AB has been merged into
A and into B:
mkdir repo_darcsimport
cd repo_darcsimport
1. import AB into a darcs directory (AB):
mkdir AB
cd AB
(cd ../../repo; git fast-export AB) | darcs convert import
cd ..
2. import the complement of AB w.r.t. A into A
darcs get AB A
cd A
(cd ../../repo; git fast-export AB..A) | darcs convert import
cd ..
2. import the complement of AB w.r.t. B into B (analoguosly)
Correct?
Yes, that should work, assuming that AB indeed refers to the splitting
point beyond which A and B differ.
Now, after I've been into exploring these things more closely, I can
tell that this is not quite possible yet with the current 'darcs
convert import'.
'darcs convert import' only creates repos from scratch. So 2. is
impossible; one can't feed extra history (in Git's notation: AB..A) to
an existing repo (A) which was initially made a clone of AB.
So I've tried another way.
I've done an experiment where I independently did an import of AB and
A into two darcs repos, hoping that the identical common source Git
commits would result in identical darcs patches, but that's not true.
cd A; darcs pull ../AB --dry-run
reports another instance of the common patch. They have different IDs.
(If someone is interested, I can post my complete shell session to
demonstrate this.)
I'm not quite sure whether this is expected and whether this could be
fixed easily. So I looked into the code, and couldn't find out why the
generated IDs should differ:
-- Darcs/Patch/Index/Types.hs:80:
makePatchID = PID . makePatchname
-- Darcs/Patch/Info.hs:282:
makePatchname :: PatchInfo - SHA1
makePatchname pi = sha1PS sha1_me
-- and PatchInfo seems to contain only the info that must be identical
for identical Git commits:
data PatchInfo = PatchInfo { _piDate:: !B.ByteString
, _piName:: !B.ByteString
, _piAuthor :: !B.ByteString
, _piLog :: ![B.ByteString]
, isInverted :: !Bool
}
--
Perhaps someone here has ideas whether the current behavior giving
non-identical patches could and should be fixed.
Best regards,
--
Ivan
___
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] currently preferred way to import history from Git
Ivan Zakharyaschev wrote:
Fri, 23 Jan 2015 17:16 +0100, Ben Franksen ben.frank...@online.de:
Ivan Zakharyaschev wrote:
2015-01-22 9:53 UTC+03:00, Ganesh Sittampalam gan...@earth.li:
'darcs convert' is currently supported.
So, I believe 'darcs convert --import' doesn't have the notion of Git
branches, does it? (At least, there are no examples of using 'darcs
convert --import' on the wiki at all, so I can only guess.)
Then, I believe, I should proceed as follows if I want to import Git
branches AB, A, B from repo repo, such that AB has been merged into
A and into B:
mkdir repo_darcsimport
cd repo_darcsimport
1. import AB into a darcs directory (AB):
mkdir AB
cd AB
(cd ../../repo; git fast-export AB) | darcs convert import
cd ..
2. import the complement of AB w.r.t. A into A
darcs get AB A
cd A
(cd ../../repo; git fast-export AB..A) | darcs convert import
cd ..
2. import the complement of AB w.r.t. B into B (analoguosly)
Correct?
Yes, that should work, assuming that AB indeed refers to the splitting
point beyond which A and B differ.
Now, after I've been into exploring these things more closely, I can
tell that this is not quite possible yet with the current 'darcs
convert import'.
'darcs convert import' only creates repos from scratch. So 2. is
impossible; one can't feed extra history (in Git's notation: AB..A) to
an existing repo (A) which was initially made a clone of AB.
This is bad. I think what is missing are --read/write-marks options for
darcs convert import. Currently only darcs convert export has those.
So I've tried another way.
I've done an experiment where I independently did an import of AB and
A into two darcs repos, hoping that the identical common source Git
commits would result in identical darcs patches, but that's not true.
cd A; darcs pull ../AB --dry-run
reports another instance of the common patch. They have different IDs.
(If someone is interested, I can post my complete shell session to
demonstrate this.)
I'm not quite sure whether this is expected and whether this could be
fixed easily. So I looked into the code, and couldn't find out why the
generated IDs should differ:
-- Darcs/Patch/Index/Types.hs:80:
makePatchID = PID . makePatchname
-- Darcs/Patch/Info.hs:282:
makePatchname :: PatchInfo - SHA1
makePatchname pi = sha1PS sha1_me
-- and PatchInfo seems to contain only the info that must be identical
for identical Git commits:
data PatchInfo = PatchInfo { _piDate:: !B.ByteString
, _piName:: !B.ByteString
, _piAuthor :: !B.ByteString
, _piLog :: ![B.ByteString]
, isInverted :: !Bool
}
This worked (though not, I believe, reliably) in some earlier 2.x versions.
Nowadays, there is a hidden field named 'salt' or some such particularly to
avoid this happening by accident (i.e. hash collision because of identical
meta data).
We should really improve the darcs convert import command so that it can
incrementally import using marks files or some other mechanism.
Cheers
Ben
--
Make it so they have to reboot after every typo. -- Scott Adams
___
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] currently preferred way to import history from Git
Ben Franksen wrote: We should really improve the darcs convert import command so that it can incrementally import using marks files or some other mechanism. It is a lot simpler than I thought. darcs convert import needs no marksfile support, that is already done by git fast-export. All that is needed is to lift some arbitrary restrictions in the implementation of darcs convert import. I have quickly hacked together a small patch that circumvents the restrictions. I really don't know for sure what I am doing here but it seems to work in a simple example. Just cd to your darcs repo (in my test it was empty), then do touch ../gitrepo/git.marks (cd ../gitrepo git fast-export --import-marks=git.marks --export- marks=git.marks) | darcs convert import When you do this again, it does not change the repo. You could test if you can convert your git repo with this. If it doesn't work I am willing to dig deeper into the matter... Cheers Ben -- Make it so they have to reboot after every typo. -- Scott Adams Note this is a very ver simple-minded and quick hack. Someone should review this and/or properly implement it. 1 patch for repository http://darcs.net/screened: patch c5d92f590be2de561746eea5d2d2be20c87c12cf Author: Ben Franksen benjamin.frank...@helmholtz-berlin.de Date: Fri Jan 23 22:26:18 CET 2015 * feature: allow darcs convert import in an existing darcs repo New patches: [feature: allow darcs convert import in an existing darcs repo Ben Franksen benjamin.frank...@helmholtz-berlin.de**20150123212618 Ignore-this: 2423b45d59d774e0a471a6f433f001bf ] hunk ./src/Darcs/UI/Commands/Convert.hs 496 -fastImport _ _ _ = fail I need exactly one output repository. +fastImport _ opts [] = do + withRepoLock NoDryRun (useCache opts) YesUpdateWorking (umask opts) $ V2Job $ \repo - do +marks - fastImport' repo emptyMarks +return marks +fastImport _ _ _ = fail I need no more than one output repository. Context: [TAG 2.9.9 Ganesh Sittampalam gan...@earth.li**20140424063828 Ignore-this: ae3cb4369f15af8cb2f19d6f5603d935 ] Patch bundle hash: 18beb25a3a2b0ca7796481ab99e26f0180ad1cd3 ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] currently preferred way to import history from Git
Ivan Zakharyaschev wrote: 2015-01-22 9:53 UTC+03:00, Ganesh Sittampalam gan...@earth.li: 'darcs convert' is currently supported. So, I believe 'darcs convert --import' doesn't have the notion of Git branches, does it? (At least, there are no examples of using 'darcs convert --import' on the wiki at all, so I can only guess.) Then, I believe, I should proceed as follows if I want to import Git branches AB, A, B from repo repo, such that AB has been merged into A and into B: mkdir repo_darcsimport cd repo_darcsimport 1. import AB into a darcs directory (AB): mkdir AB cd AB (cd ../../repo; git fast-export AB) | darcs convert import cd .. 2. import the complement of AB w.r.t. A into A darcs get AB A cd A (cd ../../repo; git fast-export AB..A) | darcs convert import cd .. 2. import the complement of AB w.r.t. B into B (analoguosly) Correct? Yes, that should work, assuming that AB indeed refers to the splitting point beyond which A and B differ. Cheers good luck with your conversion! Ben ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] currently preferred way to import history from Git
2015-01-22 13:16 UTC+03:00, Ivan Zakharyaschev i...@altlinux.org: Actually, after I make the transition to darcs, I'm thinking about a workflow with a reduced number of branches (no intersection branch AB), so I won't need a working darcs directory for AB. Does it make sense? Say, A is a feature I'm working on, and B is some implementation aspect. (In Git, I had to have the AB branch to avoid the hassle of cherry-picking a new patch from either A and B, and making sure that it is clear from the history that there is a single patch which is relevant for both A and B.) I want to add a clarification about my annoyance with Git: if I have a sequence of such A1, A2, ... branches, and B1, B2, B3, ... with the idea that A1 is a subset of A2, and so on, and B1 is a subset of B2, and so on, then it is quite tiresome to maintain the history graph clean: after I add a patch to the intersection of A1 and B1 (A1B1), I have to rebase the set of changes A1B1..A1 onto the new state of A1B1, and then A1..A2 onto the new state of A1, and so on (you get the idea). What is annoying is that I can't postpone this procedure for later, because a partially rebased history with many branches looks weird: some heads are updated, but some are left attached to the old tree, and you don't get the idea of each branch being a superset of some other one. With darcs, it would at least seem not to be so weird because you are not forced to think about the non-rebased branches as long independent branches, but rather a set merely lacking just a few new patches. When I'm hacking the implementation aspect B, I plan to work in the darcs working directory B, then pull the patches relevant for A (by interactively selecting them): cd ../A darcs pull ../B (and a similar situation will arise whenever I am working on feature A, and have touched--among other changes--the aspect B of the implementation, then I will want to pull the relevant subset of new changes into B). (There is a complication in this picture although: not to review the patches I have already decided on, I should have a dir for the last reviewed state of B, and another one--the actual working dir for B, and: cd ../A darcs pull ../B.working --complement ../B.reviewed # if successful then cd ../B.reviewed darcs pull --all ../B.working -- Ivan ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] currently preferred way to import history from Git
Hi, Thanks for all the replies! 2015-01-22 9:53 UTC+03:00, Ganesh Sittampalam gan...@earth.li: 'darcs convert' is currently supported. So, I believe 'darcs convert --import' doesn't have the notion of Git branches, does it? (At least, there are no examples of using 'darcs convert --import' on the wiki at all, so I can only guess.) Then, I believe, I should proceed as follows if I want to import Git branches AB, A, B from repo repo, such that AB has been merged into A and into B: mkdir repo_darcsimport cd repo_darcsimport 1. import AB into a darcs directory (AB): mkdir AB cd AB (cd ../../repo; git fast-export AB) | darcs convert import cd .. 2. import the complement of AB w.r.t. A into A darcs get AB A cd A (cd ../../repo; git fast-export AB..A) | darcs convert import cd .. 2. import the complement of AB w.r.t. B into B (analoguosly) Correct? Actually, after I make the transition to darcs, I'm thinking about a workflow with a reduced number of branches (no intersection branch AB), so I won't need a working darcs directory for AB. Does it make sense? Say, A is a feature I'm working on, and B is some implementation aspect. (In Git, I had to have the AB branch to avoid the hassle of cherry-picking a new patch from either A and B, and making sure that it is clear from the history that there is a single patch which is relevant for both A and B.) When I'm hacking the implementation aspect B, I plan to work in the darcs working directory B, then pull the patches relevant for A (by interactively selecting them): cd ../A darcs pull ../B (and a similar situation will arise whenever I am working on feature A, and have touched--among other changes--the aspect B of the implementation, then I will want to pull the relevant subset of new changes into B). (There is a complication in this picture although: not to review the patches I have already decided on, I should have a dir for the last reviewed state of B, and another one--the actual working dir for B, and: cd ../A darcs pull ../B.working --complement ../B.reviewed # if successful then cd ../B.reviewed darcs pull --all ../B.working I could use tags for marking reviewed patches, but then I would need a supply of numerous tags, and a flood of meaningless tags in the repo.) Whenever I want to show a simplified version of the program (without aspect B, but with feature A), I can create a temporary darcs working dir with the intersection of A and of the complement to B: mkdir A_essence cd A_essence darcs pull ../A --complement ../B These things seem not to be clarified on the wiki. At least, a note in http://darcs.net/DarcsBridgeUsage stating that it is obsolete (if this is true) and linking to the more fresh page would help. Good point, I've updated it as you suggest. Also, if I'm using darcs-2.8.4 from my distro, and according to the wiki, `darcs convert` is available in darcs-2.10 only, then should I build a new darcs or try to build darcs-bridge? I'd suggest building a new darcs and using 'darcs convert'. -- Ivan ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] currently preferred way to import history from Git
Hi Ivan, you should build darcs HEAD and use the built-in darcs convert --import/--export. It works very well and everything else is quite old. Darcs Bridge was explicitly retired IIRC. ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] currently preferred way to import history from Git
Hi, On 21/01/2015 15:51, Ivan Zakharyaschev wrote: I've started to explore the available ways to import history from Git, and have come to some uncertainty. Apologies for that, the situation is indeed a little messy. [...] Which tool should I prefer? Are they substantially different? Does `darcs convert` work better than `darcs-fastconvert` from darcs-bridge? Are there any news in this area? Note that darcs-fastconvert still exists independently of darcs-bridge, see https://hackage.haskell.org/package/darcs-fastconvert I'm not sure how up to date it is though. 'darcs convert' is currently supported. These things seem not to be clarified on the wiki. At least, a note in http://darcs.net/DarcsBridgeUsage stating that it is obsolete (if this is true) and linking to the more fresh page would help. Good point, I've updated it as you suggest. Also, if I'm using darcs-2.8.4 from my distro, and according to the wiki, `darcs convert` is available in darcs-2.10 only, then should I build a new darcs or try to build darcs-bridge? I'd suggest building a new darcs and using 'darcs convert'. Cheers, Ganesh ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
