{"thread":{"id":"18523","subject":"[PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.","startedAt":"2009-03-25T03:04:15Z","lastAt":"2009-03-25T20:38:37Z","messageCount":8,"participants":["Daniel Barkalow","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":5},"messages":[{"id":"109302","messageId":"alpine.LNX.1.00.0903242303410.19665@iabervon.org","threadId":"18523","inReplyTo":null,"subject":"[PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-25T03:04:15Z","receivedAt":"2009-03-25T03:04:15Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"---\n Documentation/git-vcs.txt | 93 ++++++++++++++++++++++++++++++++++++++\n transport.c | 109 +++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 202 insertions(+), 0 deletions(-)\n create mode 100644 Documentation/git-vcs.txt\n\ndiff --git a/Documentation/git-vcs.txt b/Documentation/git-vcs.txt\nnew file mode 100644\nindex 0000000..fa02b76\n--- /dev/null\n+++ b/Documentation/git-vcs.txt\n@@ -0,0 +1,93 @@\n+git-vcs-*(1)\n+============\n+\n+NAME\n+----\n+git-vcs-* - Helper programs for interoperation with foreign systems\n+\n+SYNOPSIS\n+--------\n+'git vcs-' [options] [arguments]\n+\n+DESCRIPTION\n+-----------\n+\n+These programs are normally not used directly by end users, but are\n+invoked by various git programs that interact with remote repositories\n+when the repository they would operate on is part of a foreign\n+system.\n+\n+Each 'git vcs-' is a helper for interoperating with a\n+particular version control system. Different helpers have different\n+capabilities (limited both be the particular helper and by the\n+capabilities of the system they connect to), and they report what\n+capabilities they support.\n+\n+In general, these programs interact with a portion of the refs\n+namespace that isn't used by the rest of git. The configuration will\n+then (generally) map these refs into the remotes namespace. This\n+allows the importer to do whatever it wants with its refs without\n+affecting the state visible to normal git programs.\n+\n+COMMANDS\n+--------\n+\n+'capabilities'::\n+\tPrints the capabilities of the helper, one per line. These are:\n+\t - import: the basic import command\n+\t - marks: import should be done with a saved marks file\n+\t - find-new-branches: detect new branches\n+\t - export: the general export command\n+\t - fork: create a new branch and export to it\n+\t - anonymous-fork: make commits on a branch without an inherent name\n+\t - merge: merge branches (of whatever type the system supports)\n+\n+\tIf the helper doesn't support \"merge\", the default for pull is\n+\tto rebase instead of merging.\n+\n+'list'::\n+\tTakes the remote name, and outputs the names of refs. These\n+\tmay be followed, after a single space, by \"changed\" or\n+\t\"unchanged\", indicating whether the foreign repository has\n+\tchanged from the state in the ref. If the helper doesn't know,\n+\tit doesn't have to provide a value. (In particular, it\n+\tshouldn't do expensive operations, such as importing the\n+\tcontent, to see whether it matches.)\n+\n+'import'::\n+\tTakes the remote name and a list of names of refs, and imports\n+\twhatever it describes, by outputting it in git-fast-import\n+\tformat.\n+\n+'export'::\n+\tSends the branch to the foreign system and reimports it in\n+\tfast-import format.\n+\n+\tReads a list of commits from stdin, where each commit has no\n+\tparents which were neither produced by an earlier import nor\n+\tappearing earlier in the list, where some commit has the old\n+\tvalue of the branch as a parent, and where all commits listed\n+\tare ancestors of the last one. Furthermore:\n+\n+\t - if the system doesn't support merges, each of these commits\n+\t has only a single parent;\n+\n+\t - if the system doesn't support anonymous branches, the first\n+\t commit has the old value of the branch as a parent (if the\n+\t branch already had a value), and all parents are either the\n+\t commit listed immediately before or produced by an earlier\n+\t import;\n+\n+\t - if the system doesn't support many-way merges, each commit\n+\t has at most two parents.\n+\n+\texport produces output in fast-import format giving the\n+\tcontent after a round-trip through the foreign system. This\n+\talso contains extra headers to report the mapping of original\n+\tgit commits to reimported git commits (to facilitate rewriting\n+\tlocal branches to use the history-as-reimported instead of the\n+\tgit-only version).\n+\n+\texport reports how much it managed to export by producing\n+\tcommits in the fast-import stream that replace the listed\n+\titems that were successfully exported.\ndiff --git a/transport.c b/transport.c\nindex 8a37db5..fe78169 100644\n--- a/transport.c\n+++ b/transport.c\n@@ -916,6 +916,113 @@ static int disconnect_git(struct transport *transport)\n \treturn 0;\n }\n \n+static int fetch_refs_via_foreign(struct transport *transport,\n+\t\t\t\t int nr_heads, struct ref **to_fetch)\n+{\n+\tstruct remote *remote = transport->remote;\n+\tstruct child_process importer;\n+\tstruct child_process fastimport;\n+\tstruct ref *posn;\n+\tint i, count;\n+\tstruct strbuf buf;\n+\n+\tmemset(&importer, 0, sizeof(importer));\n+\timporter.in = 0;\n+\timporter.no_stdin = 1;\n+\timporter.out = -1;\n+\timporter.err = 0;\n+\timporter.argv = xcalloc(5 + nr_heads, sizeof(*importer.argv));\n+\tstrbuf_init(&buf, 80);\n+\tstrbuf_addf(&buf, \"vcs-%s\", remote->foreign_vcs);\n+\timporter.argv[0] = buf.buf;\n+\timporter.argv[1] = \"import\";\n+\timporter.argv[2] = remote->name;\n+\tcount = 0;\n+\tfor (i = 0; i < nr_heads; i++) {\n+\t\tposn = to_fetch[i];\n+\t\tif (posn->status & REF_STATUS_UPTODATE)\n+\t\t\tcontinue;\n+\t\timporter.argv[3 + count] = posn->name;\n+\t\tcount++;\n+\t}\n+\timporter.git_cmd = 1;\n+\tif (count) {\n+\t\tstart_command(&importer);\n+\n+\t\tmemset(&fastimport, 0, sizeof(fastimport));\n+\t\tfastimport.in = importer.out;\n+\t\tfastimport.argv = xcalloc(3, sizeof(*fastimport.argv));\n+\t\tfastimport.argv[0] = \"fast-import\";\n+\t\tfastimport.argv[1] = \"--quiet\";\n+\t\tfastimport.git_cmd = 1;\n+\t\tstart_command(&fastimport);\n+\n+\t\tfinish_command(&importer);\n+\t\tfinish_command(&fastimport);\n+\t}\n+\tstrbuf_release(&buf);\n+\tfor (i = 0; i < nr_heads; i++) {\n+\t\tposn = to_fetch[i];\n+\t\tif (posn->status & REF_STATUS_UPTODATE)\n+\t\t\tcontinue;\n+\t\tread_ref(posn->name, posn->old_sha1);\n+\t\tcount++;\n+\t}\n+\treturn 0;\n+}\n+\n+static struct ref *get_refs_via_foreign(struct transport *transport)\n+{\n+\tstruct remote *remote = transport->remote;\n+\tstruct child_process importer;\n+\tstruct ref *ret = NULL;\n+\tstruct ref **end = &ret;\n+\tstruct strbuf buf;\n+\tmemset(&importer, 0, sizeof(importer));\n+\timporter.in = 0;\n+\timporter.no_stdin = 1;\n+\timporter.out = -1;\n+\timporter.err = 0;\n+\timporter.argv = xcalloc(5, sizeof(*importer.argv));\n+\tstrbuf_init(&buf, 80);\n+\tstrbuf_addf(&buf, \"vcs-%s\", remote->foreign_vcs);\n+\timporter.argv[0] = buf.buf;\n+\timporter.argv[1] = \"list\";\n+\timporter.argv[2] = remote->name;\n+\timporter.git_cmd = 1;\n+\tstart_command(&importer);\n+\n+\tstrbuf_reset(&buf);\n+\twhile (1) {\n+\t\tchar *eol, *eon;\n+\t\tif (strbuf_read(&buf, importer.out, 80) <= 0)\n+\t\t\tbreak;\n+\t\twhile (1) {\n+\t\t\teol = strchr(buf.buf, '\\n');\n+\t\t\tif (!eol)\n+\t\t\t\tbreak;\n+\t\t\t*eol = '\\0';\n+\t\t\teon = strchr(buf.buf, ' ');\n+\t\t\tif (eon)\n+\t\t\t\t*eon = '\\0';\n+\t\t\t*end = alloc_ref(buf.buf);\n+\t\t\tif (eon) {\n+\t\t\t\tif (strstr(eon + 1, \"unchanged\")) {\n+\t\t\t\t\t(*end)->status |= REF_STATUS_UPTODATE;\n+\t\t\t\t\tif (read_ref((*end)->name, (*end)->old_sha1))\n+\t\t\t\t\t\tdie(\"Unchanged?\");\n+\t\t\t\t}\n+\t\t\t}\n+\t\t\tend = &((*end)->next);\n+\t\t\tstrbuf_remove(&buf, 0, eol - buf.buf + 1);\n+\t\t}\n+\t}\n+\n+\tfinish_command(&importer);\n+\tstrbuf_release(&buf);\n+\treturn ret;\n+}\n+\n static int is_local(const char *url)\n {\n \tconst char *colon = strchr(url, ':');\n@@ -940,6 +1047,8 @@ struct transport *transport_get(struct remote *remote, const char *url)\n \tret->url = url;\n \n \tif (remote && remote->foreign_vcs) {\n+\t\tret->get_refs_list = get_refs_via_foreign;\n+\t\tret->fetch = fetch_refs_via_foreign;\n \t} else if (!prefixcmp(url, \"rsync:\")) {\n \t\tret->get_refs_list = get_refs_via_rsync;\n \t\tret->fetch = fetch_objs_via_rsync;\n-- \n1.6.2.1.476.g9bf04b\n"},{"id":"109324","messageId":"7vskl284bt.fsf@gitster.siamese.dyndns.org","threadId":"18523","inReplyTo":"alpine.LNX.1.00.0903242303410.19665@iabervon.org","subject":"Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-25T07:11:18Z","receivedAt":"2009-03-25T07:11:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> +'capabilities'::\n> +\tPrints the capabilities of the helper, one per line. These are:\n> +\t - import: the basic import command\n> +\t - marks: import should be done with a saved marks file\n> +\t - find-new-branches: detect new branches\n> +\t - export: the general export command\n> +\t - fork: create a new branch and export to it\n> +\t - anonymous-fork: make commits on a branch without an inherent name\n> +\t - merge: merge branches (of whatever type the system supports)\n> +\n> +\tIf the helper doesn't support \"merge\", the default for pull is\n> +\tto rebase instead of merging.\n> +\n> +'list'::\n> +\tTakes the remote name, and outputs the names of refs. These\n> +\tmay be followed, after a single space, by \"changed\" or\n> +\t\"unchanged\", indicating whether the foreign repository has\n> +\tchanged from the state in the ref. If the helper doesn't know,\n> +\tit doesn't have to provide a value. (In particular, it\n> +\tshouldn't do expensive operations, such as importing the\n> +\tcontent, to see whether it matches.)\n\nDoes this roughly corresponds to get_remote_refs(), with \"unchanged\"\nreturn turned into the current value of the ref while \"changed\" returned\nas 0{40} in old_sha1 value?\n\nFor a vcs backend that lacks find-new-branches capability, when does the\nset of refnames returned by this operation change? Can the end user\nrequest an expensive operation to make the list up-to-date? Does the end\nuser need to?\n\n> +'import'::\n> +\tTakes the remote name and a list of names of refs, and imports\n> +\twhatever it describes, by outputting it in git-fast-import\n> +\tformat.\n> +\n> +'export'::\n> +\tSends the branch to the foreign system and reimports it in\n> +\tfast-import format.\n\nThe above two description is inconsistent; say \"git-fast-import\" for both.\n\nThis seems to follow the model of git-svn in that we treat our history as\nthrow-away, export the history and give the authority to the other system\nby discarding and replacing our history with whatever the other end gives\nback to us by re-importing. Because git is more flexible than anything\nelse, we could afford to do so, but I wonder if it is the right model and\nmentality.\n\nOne downside is that you end up rebasing the git side by operating this\nway, and a topology where multiple developers use one git repository as a\nsynchronization point and use that git repository to interface with the\nforeign system becomes impossible. Instead, these multiple developers\nneed to treat the foreign system as the central repository, and interface\nwith it individually.\n"},{"id":"109369","messageId":"alpine.LNX.1.00.0903251050430.19665@iabervon.org","threadId":"18523","inReplyTo":"7vskl284bt.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-25T16:20:13Z","receivedAt":"2009-03-25T16:20:13Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 25 Mar 2009, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > +'capabilities'::\n> > +\tPrints the capabilities of the helper, one per line. These are:\n> > +\t - import: the basic import command\n> > +\t - marks: import should be done with a saved marks file\n> > +\t - find-new-branches: detect new branches\n> > +\t - export: the general export command\n> > +\t - fork: create a new branch and export to it\n> > +\t - anonymous-fork: make commits on a branch without an inherent name\n> > +\t - merge: merge branches (of whatever type the system supports)\n> > +\n> > +\tIf the helper doesn't support \"merge\", the default for pull is\n> > +\tto rebase instead of merging.\n> > +\n> > +'list'::\n> > +\tTakes the remote name, and outputs the names of refs. These\n> > +\tmay be followed, after a single space, by \"changed\" or\n> > +\t\"unchanged\", indicating whether the foreign repository has\n> > +\tchanged from the state in the ref. If the helper doesn't know,\n> > +\tit doesn't have to provide a value. (In particular, it\n> > +\tshouldn't do expensive operations, such as importing the\n> > +\tcontent, to see whether it matches.)\n> \n> Does this roughly corresponds to get_remote_refs(), with \"unchanged\"\n> return turned into the current value of the ref while \"changed\" returned\n> as 0{40} in old_sha1 value?\n\nYes, with the [1/5] change to make 0{40} tell git to consider it different \nbut unknown. Also, not giving either of these flags counts as 0{40}, but \nwe might someday want to have the native side report the difference \nbetween knowing that it changed and not knowing at all.\n\n> For a vcs backend that lacks find-new-branches capability, when does the\n> set of refnames returned by this operation change? Can the end user\n> request an expensive operation to make the list up-to-date? Does the end\n> user need to?\n\nWhat I've done for my p4 backend is have an option for whether it should \nsearch for new branches (which is somewhat expensive, at least currently, \nbecause it involves connecting to the server in this step). If the backend \nactually lacks the capability, the user has to do something (probably add \nthem to the config file) to include new branches. In some cases, what the \nbackend exposes as branches may be something that there isn't a complete \nlist of; there may be systems that are structured sort of like repo.or.cz, \nwhere the URL is for the whole system, and there are some things on it \nthat are branches of the project (like various people's git.git \nrepositories) and some things that are completely unrelated and not \ninteresting, and there's no machine-readable way to distinguish them.\n\n> > +'import'::\n> > +\tTakes the remote name and a list of names of refs, and imports\n> > +\twhatever it describes, by outputting it in git-fast-import\n> > +\tformat.\n> > +\n> > +'export'::\n> > +\tSends the branch to the foreign system and reimports it in\n> > +\tfast-import format.\n> \n> The above two description is inconsistent; say \"git-fast-import\" for both.\n\nNot \"fast-import\" for both, now that other systems have adopted the format \nas input?\n\n> This seems to follow the model of git-svn in that we treat our history as\n> throw-away, export the history and give the authority to the other system\n> by discarding and replacing our history with whatever the other end gives\n> back to us by re-importing. Because git is more flexible than anything\n> else, we could afford to do so, but I wonder if it is the right model and\n> mentality.\n\nI think that there is always the requirement that the other system \n(whether it's foreign, git through filter-branch, or even a regular remote \ngit repository) contains a sane, consistant, and normal-looking history. \nIt's rarely going to be possible to export a history that will import as \nthe same hash (and incremental imports on top of local history that isn't \nwhat a fresh complete import would contain seems even crazier). I don't \nthink there's any particular use for using a foreign system to store \nhistory that only makes sense in git.\n\nBut, as a general principle, the reason a git developer would push to a \nnon-git remote repository is because the remote repository is \nauthoritative. I don't think it makes sense to have an environment where \nthe authoritative history is in git, but people are sharing it through a \nbzr server (even if the bzr server can accurately represent the git \nhistory).\n\nOf course, we may want a different mechanism some day to generalize \ngit-cvsserver, where the authoritative history is in git, but we're \nsupporting foreign clients. But that requires very different code from \nwhat I'm working on.\n\n> One downside is that you end up rebasing the git side by operating this\n> way, and a topology where multiple developers use one git repository as a\n> synchronization point and use that git repository to interface with the\n> foreign system becomes impossible. Instead, these multiple developers\n> need to treat the foreign system as the central repository, and interface\n> with it individually.\n\nYeah, this is unfortunate. You can at least import through a shared \nsystem, which is pretty close to how git.git development goes (we pull \nfrom your public repo, make changes locally, and email patches, which you \nput in upstream, and we get back commits that are not the same hash we \ncreated locally).\n\nI think it might be possible to do something where the synchronization \npoint has a list of authoritative commit-swaps, where it can tell the \nmultiple developers: \"commit Y is really the same thing as commit X; they \nhave the same tree, and their parents Y1..Yn are the same as X1..Xn \n(either based on the same criterion applied recursively, or having \nidentical hashes)\". This list of commit-swaps allows the developers to be \ncomfortable with trivial rebases (in a commit Z with X as a parent, make a \ncommit Z' with Y replacing X and no other changes, and replace Z with Z' \nin refs and other commits). Of course, this depends on being able to get \nthe foreign system to agree on both complete content and history topology, \nbut otherwise we kind of have to throw away our history, because the \npublic history simply can't be like what we've made locally.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"109378","messageId":"7vocvp7b31.fsf@gitster.siamese.dyndns.org","threadId":"18523","inReplyTo":"alpine.LNX.1.00.0903251050430.19665@iabervon.org","subject":"Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-25T17:42:58Z","receivedAt":"2009-03-25T17:42:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n>> > +'import'::\n>> > +\tTakes the remote name and a list of names of refs, and imports\n>> > +\twhatever it describes, by outputting it in git-fast-import\n>> > +\tformat.\n>> > +\n>> > +'export'::\n>> > +\tSends the branch to the foreign system and reimports it in\n>> > +\tfast-import format.\n>> \n>> The above two description is inconsistent; say \"git-fast-import\" for both.\n>\n> Not \"fast-import\" for both, now that other systems have adopted the format \n> as input?\n\nI did not mean anything deeper than just pointing out that one sentence\ncalls the format \"git-fast-import format\" and the other one calls\n\"fast-import format\".\n"},{"id":"109383","messageId":"7vbprp5vko.fsf@gitster.siamese.dyndns.org","threadId":"18523","inReplyTo":"alpine.LNX.1.00.0903251050430.19665@iabervon.org","subject":"Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-25T18:03:19Z","receivedAt":"2009-03-25T18:03:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> On Wed, 25 Mar 2009, Junio C Hamano wrote:\n>\n>> This seems to follow the model of git-svn in that we treat our history as\n>> throw-away, export the history and give the authority to the other system\n>> by discarding and replacing our history with whatever the other end gives\n>> back to us by re-importing. Because git is more flexible than anything\n>> else, we could afford to do so, but I wonder if it is the right model and\n>> mentality.\n> ...\n> But, as a general principle, the reason a git developer would push to a\n> non-git remote repository is because the remote repository is\n> authoritative. I don't think it makes sense to have an environment\n> where the authoritative history is in git, but people are sharing it\n> through a bzr server (even if the bzr server can accurately represent\n> the git history).\n\nSuppose a project used to use subversion, but it migrated to git (not an\nunheard-of scenario these days, I hope). The git repository now is the\nauthoritative one, all the development happens on this side.\n\nBut in order to help:\n\n - people who have established their workflow to follow the project\n (e.g. not necessarily contributing anything back, but just doing\n regular \"svn update\");\n\n - people who have leftover local changes from the subversion days; and\n\n - other project infrastracture (e.g. trac) that the project hasn't\n managed to interface to the new git repository yet;\n\nthe project decides to keep feeding recent updates to the subversion\nrepository that used to be authoritative, even though it is now declared\nread-only (i.e. the only update comes from the git end).\n\nMy understanding is that the above scenario would not work if git-vcs-svn\nrewrites commits when git exports to svn, and existing git-svn two-way\ninterface using its \"dcommit\" may have exactly the same issue.\n\nThe reason I brought this up was to involve people who have already faced\nthis issue with git-svn in the discussion to see if we can avoid it by\ndoing somethink similar to clever tricks they are using in their git-svn\nworkflow, if there are some. Perhaps your paragraph below may be one of\nthose clever tricks, but there may be others.\n\n> I think it might be possible to do something where the synchronization \n> point has a list of authoritative commit-swaps, where it can tell the \n> multiple developers: \"commit Y is really the same thing as commit X; they \n> have the same tree, and their parents Y1..Yn are the same as X1..Xn \n> (either based on the same criterion applied recursively, or having \n> identical hashes)\". This list of commit-swaps allows the developers to be \n> comfortable with trivial rebases (in a commit Z with X as a parent, make a \n> commit Z' with Y replacing X and no other changes, and replace Z with Z' \n> in refs and other commits). Of course, this depends on being able to get \n> the foreign system to agree on both complete content and history topology, \n> but otherwise we kind of have to throw away our history, because the \n> public history simply can't be like what we've made locally.\n"},{"id":"109403","messageId":"alpine.LNX.1.00.0903251446180.19665@iabervon.org","threadId":"18523","inReplyTo":"7vbprp5vko.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-25T19:28:23Z","receivedAt":"2009-03-25T19:28:23Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 25 Mar 2009, Junio C Hamano wrote:\n\n> Suppose a project used to use subversion, but it migrated to git (not an\n> unheard-of scenario these days, I hope). The git repository now is the\n> authoritative one, all the development happens on this side.\n> \n> But in order to help:\n> \n> - people who have established their workflow to follow the project\n> (e.g. not necessarily contributing anything back, but just doing\n> regular \"svn update\");\n> \n> - people who have leftover local changes from the subversion days; and\n> \n> - other project infrastracture (e.g. trac) that the project hasn't\n> managed to interface to the new git repository yet;\n> \n> the project decides to keep feeding recent updates to the subversion\n> repository that used to be authoritative, even though it is now declared\n> read-only (i.e. the only update comes from the git end).\n\nActually, this is easy: just configure the git repo to not fetch anything \nfrom the no-longer-authoritative subversion repository. git-vcs-svn would \nwaste a bunch of time reimporting what it exported, but it wouldn't \nactually do anything with it (since it doesn't even have tracking refs to \nupdate). It could, of course, be optimized to avoid reimporting if it \ndoesn't need to.\n\n> My understanding is that the above scenario would not work if git-vcs-svn\n> rewrites commits when git exports to svn, and existing git-svn two-way\n> interface using its \"dcommit\" may have exactly the same issue.\n> \n> The reason I brought this up was to involve people who have already faced\n> this issue with git-svn in the discussion to see if we can avoid it by\n> doing somethink similar to clever tricks they are using in their git-svn\n> workflow, if there are some. Perhaps your paragraph below may be one of\n> those clever tricks, but there may be others.\n\nThe harder problem is that you can only push history that the remote \nsystem will be able to represent. In the same way that git wants your push \nto be a fast-forward, svn wants your push to not contain any merges (and \np4 and svn both want your push to not contain parallel development \npushed to a single branch). Rewriting the history to conform to the \ndestination's requirements is most of what dcommit does, I believe.\n\nI think that, in this use case, the right thing is to have a config option \nfor git-vcs-svn to tell it to collapse the problematic commits (or maybe \ncollapse all commits in a push). That would make the svn history export \nlike the reflog, which is all linear and simple anyway, and probably \nsufficient for the above users of the old repository.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"109405","messageId":"7vskl1xuez.fsf@gitster.siamese.dyndns.org","threadId":"18523","inReplyTo":"alpine.LNX.1.00.0903251446180.19665@iabervon.org","subject":"Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-25T19:40:52Z","receivedAt":"2009-03-25T19:40:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> On Wed, 25 Mar 2009, Junio C Hamano wrote:\n>\n>> Suppose a project used to use subversion, but it migrated to git (not an\n>> unheard-of scenario these days, I hope). The git repository now is the\n>> authoritative one, all the development happens on this side.\n>> \n>> But in order to help:\n>> \n>> - people who have established their workflow to follow the project\n>> (e.g. not necessarily contributing anything back, but just doing\n>> regular \"svn update\");\n>> \n>> - people who have leftover local changes from the subversion days; and\n>> \n>> - other project infrastracture (e.g. trac) that the project hasn't\n>> managed to interface to the new git repository yet;\n>> \n>> the project decides to keep feeding recent updates to the subversion\n>> repository that used to be authoritative, even though it is now declared\n>> read-only (i.e. the only update comes from the git end).\n>\n> Actually, this is easy: just configure the git repo to not fetch anything \n> from the no-longer-authoritative subversion repository. git-vcs-svn would \n> waste a bunch of time reimporting what it exported, but it wouldn't \n> actually do anything with it (since it doesn't even have tracking refs to \n> update). It could, of course, be optimized to avoid reimporting if it \n> doesn't need to.\n\nI am afraid that won't fly; my comment that started this subthread was not\nabout your \"import\" but was about your \"export\" part. It is about sending\nthe git branch to the other end, which is allowed to rewrite what we send\nand force us to modify our history.\n"},{"id":"109412","messageId":"alpine.LNX.1.00.0903251611140.19665@iabervon.org","threadId":"18523","inReplyTo":"7vskl1xuez.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-25T20:38:37Z","receivedAt":"2009-03-25T20:38:37Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 25 Mar 2009, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > On Wed, 25 Mar 2009, Junio C Hamano wrote:\n> >\n> >> Suppose a project used to use subversion, but it migrated to git (not an\n> >> unheard-of scenario these days, I hope). The git repository now is the\n> >> authoritative one, all the development happens on this side.\n> >> \n> >> But in order to help:\n> >> \n> >> - people who have established their workflow to follow the project\n> >> (e.g. not necessarily contributing anything back, but just doing\n> >> regular \"svn update\");\n> >> \n> >> - people who have leftover local changes from the subversion days; and\n> >> \n> >> - other project infrastracture (e.g. trac) that the project hasn't\n> >> managed to interface to the new git repository yet;\n> >> \n> >> the project decides to keep feeding recent updates to the subversion\n> >> repository that used to be authoritative, even though it is now declared\n> >> read-only (i.e. the only update comes from the git end).\n> >\n> > Actually, this is easy: just configure the git repo to not fetch anything \n> > from the no-longer-authoritative subversion repository. git-vcs-svn would \n> > waste a bunch of time reimporting what it exported, but it wouldn't \n> > actually do anything with it (since it doesn't even have tracking refs to \n> > update). It could, of course, be optimized to avoid reimporting if it \n> > doesn't need to.\n> \n> I am afraid that won't fly; my comment that started this subthread was not\n> about your \"import\" but was about your \"export\" part. It is about sending\n> the git branch to the other end, which is allowed to rewrite what we send\n> and force us to modify our history.\n\nIt can rewrite what we send, but if we're not reimporting it, we don't \ncare what it's done. All we care about is that when we ignore the \nrewriting, git-vcs-* can still export more changes from our version of the \nhistory.\n\nThat is, if we push X, which gets rewritten to X' (but we ignore that), \nand we then push Y, whose parent is X (not X'), a high-quality git-vcs \nbackend will be reliably able to accept the second push, just as if we'd \ncreated a Y' based on X'. And by \"high-quality\", I mean some testable \ncapability with a better name.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}